~fdlamotte

Recent activity

Re: [PATCH sxmo-utils] V2 Tentative to modularize inputhandler 16 days ago

From Florent de Lamotte to ~mil/sxmo-devel

Hi,

Totally agree with you ... my work is available and can be carried on,
that is more than I ask ;)

And in the meantime I'll document it for the ones wanting to have it on
their side ...

Regards,
--
Florent

Re: [PATCH sxmo-utils] V2 Tentative to modularize inputhandler 16 days ago

From Florent de Lamotte to ~mil/sxmo-devel

Hi,

Just a friendly ping since I have had no response about this thread ;)

The build failed but it did not seem too bad (I've made it pass on my
side) :
 - one reason is from the "dynamic" sourcing of scripts
 - the other came from the for loop (and I still don't know which way is
   better for writing it)

In the last month I had some time to think about this refactoring and
while it is necessary on my phone because I have defined a lot of
gestures It might not be the case for the default install, where
gestures does not seem to be used a lot ...

[PATCH sxmo-utils] V2 Tentative to modularize inputhandler a month ago

From Florent de Lamotte to ~mil/sxmo-devel

Hi,

Here is a new tentative, trying to take into account your comments. I
hope code quality is better, tried to be a little cleaner ;)

I have not yet dealt with migration as I'd need to study a little how
to set this up ...

The biggest change is the sourcing of action scripts, this simplifies a
lot of things and added some speed gains.

I have also tried different approaches for the loop :
 1- for action_path in "$action_dir"/*; do
[message trimmed]

Re: [PATCH sxmo-utils] Tentative to modularize inputhandler a month ago

From Florent de Lamotte to ~mil/sxmo-devel

Hi Stacy and Aren,

Made some progress yesterday (bored at work ;)) and think I need some
guidance.

First, the sourcing of scripts has been a great success, on performance
side, there is a 2-3ms improvement, but that is on the readability that
the gain is important, exit structure is clearer ;). Now I am faster
than the original script on the op6 ... (I'd need to check profundly but
it is not bad)

Where I need you is for two points :
 - loop structure

Re: [PATCH sxmo-utils] Tentative to modularize inputhandler a month ago

From Florent de Lamotte to ~mil/sxmo-devel

> I agree with Aren here. The idea is interesting and I am willing to help
> on this, but only if (1) there is no performance impact, (2)
> sxmo_migrate.sh manage them, and (3) it is still easy for user to
> add/expand them.
>
> I mark this as needing_revision anyway.

Thanks for the comments, it will definitely make the code better ... I
think it is obvious that I'm more a tinkerer than a programmer so I need
some guidance there ...

As this is getting interest I will go deeper. I have to experiment
different constructs and see the impact on perfs/usability, so I might
not reply quickly, but work is underway.

Re: [PATCH sxmo-utils] Tentative to modularize inputhandler a month ago

From Florent de Lamotte to ~mil/sxmo-devel

Hi Aren, 

Thanks for taking the time to review my patch, your comments are
relevant and will help me provide a better solution (at least for my 
use ;)).

I will not reply to everything now and will take some time to take
everyting into account (if you find there is some interest in my proposal).

> What do we gain from this? Is the idea that users can add actions for
> apps and have to deal less with conflicts when upgrading?

Well, I did this mainly for myself because my own sxmo_hook_inputhandler.sh
was growing out of control, and yes it is clearly a pain when upgrading.

[PATCH sxmo-utils] Tentative to modularize inputhandler a month ago

From Florent de Lamotte to ~mil/sxmo-devel

The idea is to split the big switch into sxmo_hook_inputhandler.sh into
a script for each possible action. These script are stored in local and
global inputhandler.d directories.

Some benchmarks have been done with hyperfine on op6 and moto-g3. On op6
the scripts runs in 50ms, on moto-g3, there is a small penalty (from
105ms to 110ms).

Some optimizations can be done, for instance the loop could be exited as
soon as the first match has been found. Currently I let it continue, it
enables some sort of "inheritance" ...

---
[message trimmed]

Re: [PATCH] POC for adding received images preview in the log 2 years ago

From Florent de Lamotte to ~mil/sxmo-devel

> BTW, Florent, I tested this on foot and it works great. But st does not
> support sixel. My brief googling reveals a load of patches on patches,
> but I wasn't able to track down some sort of officialish sixel patch for
> st. Is there one?

Thanks for digging into this !

You're right I was sure I had seen that st supports sixel but didn't
care to test (I've started using sxmo with 1.6)

There is a sixel branch in siduck/st from github :
 https://github.com/siduck/st/tree/sixel

Unfortunately there are a minority of terminals supporting sixel, and it

Re: [PATCH] POC for adding received images preview in the log 2 years ago

From Florent de Lamotte to ~mil/sxmo-devel

> Mhh you can prefix your patch with POC or WIP to make it explicit.
> Should be enough for avoid it to be merged.

Ok, I see ... sorry for the inconvenience

I'm not yet totally familiar with the git-email workflow (that I find
neat btw), so I added POC in the commit line and didn't know I should
change the subject ;)

> Mhh I'm not sure we could provide a way to mix text and mms content
> (except for text mms). The best way would eventually be to link the file
> path as file://blabla/foo/bar.png so that you can open it with the
> terminal (click on it).

Re: [PATCH] POC for adding received images preview in the log 2 years ago

From Florent de Lamotte to ~mil/sxmo-devel

> How do you know that the terminal the user use support sixel ?
> Plus I'm not usre we want this cause maybe the user pipe this text
> file into something else (bots, bridges, etc)

I totally agree this is not ok at the moment, there are a lot of issues
behind ...

I would certainly not advise to integrate this !

That is why I stated this was a proof of concept ... to show the
feasibility. Maybe there is another channel more adequate to post these
kinds of experiments ?