>I have experimented with the same in the (default) desktop containment,
>and I
>think it's quite easy to try with a small adjustment in the code (would
>need
>to look it up, I haven't touched that code in a while).
I saw the vestiges of that (FV is forked off the Desktop code, which really
ne
On Friday, February 13, 2015 23:55:24 Eike Hein wrote:
> > one thing is that it would break if any applet decides to manage press nad
> > hold i guess (not any current applet i know, but since is a standard
> > signal in MouseArea, hmm)
>
> It don't think it would though: The MEL underneath the ap
On Friday, February 13, 2015 23:55:24 Eike Hein wrote:
> > one thing is that it would break if any applet decides to manage press nad
> > hold i guess (not any current applet i know, but since is a standard
> > signal in MouseArea, hmm)
>
> It don't think it would though: The MEL underneath the ap
On 02/13/2015 04:27 PM, Marco Martin wrote:
I don't think so, locked means locked.. especially for kiosk setups where it
would be systemimmutable the expected behavior is that there should just not
be any ways to move anything in any way
Yes, the concept of 'locked' needs to remain in the cod
On Friday 13 February 2015, Eike Hein wrote:
> Hi,
>
> yesterday I added a new "Experimental" page to the config dialog
> of the Folder View desktop containment in master. It offers two
> options that enable a different way of interacting with widgets
> on the desktop:
>
> - Pressing and holding
Hi,
yesterday I added a new "Experimental" page to the config dialog
of the Folder View desktop containment in master. It offers two
options that enable a different way of interacting with widgets
on the desktop:
- Pressing and holding for $platform_delay to engage a 'move' mode
where as long
