Bug 2639 - Home view needs to have an option to lock desktop applets into place
: Home view needs to have an option to lock desktop applets into place
Status: RESOLVED FIXED
Product: Desktop platform
Home
: 4.0
: N800 Maemo
: Medium enhancement with 52 votes (vote)
: 5.0-beta
Assigned To: unassigned
: user-interaction-bugs
:
: community-diablo, patch
:
:
  Show dependency tree
 
Reported: 2007-12-22 13:53 UTC by robert boucher
Modified: 2009-10-22 07:56 UTC (History)
15 users (show)

See Also:


Attachments
initial attempt at adding a drag lock (4.79 KB, patch)
2008-11-18 01:41 UTC, rafi
Details
1/3 debs (145.07 KB, application/octet-stream)
2008-11-19 03:55 UTC, rafi
Details
2/3 (125.31 KB, application/x-debian-package)
2008-11-19 03:56 UTC, rafi
Details
3/3 (68.81 KB, application/x-debian-package)
2008-11-19 03:56 UTC, rafi
Details
tarbal with 10 debs, including the dev and dbg versions. (1.25 MB, application/octet-stream)
2008-11-19 04:02 UTC, rafi
Details
Little cleanup of the drag lock behavior. (5.12 KB, patch)
2008-11-19 17:10 UTC, rafi
Details
Binaries for people to try drag lock v2 (1.27 MB, application/octet-stream)
2008-11-19 17:12 UTC, rafi
Details
made drag_lock a static field so all applets have consistent state (4.82 KB, patch)
2008-11-19 19:14 UTC, rafi
Details
made drag_lock a static field so all applets have consistent state (4.82 KB, patch)
2008-11-19 19:14 UTC, rafi
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description robert boucher (reporter) 2007-12-22 13:53:08 UTC
Once a user has selected and placed the applets on the desktop, there should be
a mechanism to lock there position down.

When using a finger on the touch screen to select a control within an applet
(FM Radio) or to launch an application via the applet, the action actually
moves the applet on the desktop instead of the selecting intended action.
Comment 1 Roope Rainisto nokia 2008-01-02 10:10:11 UTC
I agree on this... Let's see what we can do about this: it's one part of a
bigger puzzle we're working on.
Comment 2 Randall Arnold 2008-01-09 00:38:45 UTC
Roope, buddy, here's my suggestion:

1. locking/unlocking needs to be restored. I recommend that a Press-and-Hold
click mode be added to applets that brings up a customary "right click" context
menu with lock/unlock functions. Of course, press-and-hold needs to be
distinguished from short clicks just as it is for other purposes. This should
solve the accidental jostling of applets on tablet awakening.

2. As for positioning, the solution is simple: take a page from Adobe
Illustrator and provide grids and guidelines. Specifically, once a user begins
dragging an applet around the screen, a temporary grid appears against the
background image. Display-spanning guidelines appear on key applet edges when
they are aligned with other applets, for snapping into place. Taken further,
the grid and related settings could even be configurable via the desktop menu.

solved.  ; )
Comment 3 Roope Rainisto nokia 2008-01-09 10:17:35 UTC
Yes...

For 1) I doubt that all people would find this functionality. And having to do
lock/unlock on an applet-by-applet -basis imho isn't ideal. The user either
wants to rearrange all of them, in relation to each other, or then not. Or if
you mean that the lock/unlock would apply to all of them, placing this command
into the context-sensitive menu of one item would then be slightly off.

For 2) it's something we've been considering, but the implementation effort
isn't totally trivial.

Still, this is one area we are working on, but unfortunately I cannot give all
the details right now. :)
Comment 4 Walt Bilofsky 2008-01-09 20:05:11 UTC
How about putting the context menu on unoccupied areas of the desktop.  This
will be familiar to Windows users and will leave each applet free to have its
own context menu if desired. It should also be on the pulldown menu.

Grid lines could be a lot of work for little additional benefit. How about a
simple "snap to grid" option next to lock/unlock (again, as Windows does)?
Comment 5 Roope Rainisto nokia 2008-01-10 14:37:26 UTC
The fundamental problem with context-menus is (well, there are many, but) that
not all users will find them. So although we can certainly have them to assist
in some cases, they shouldn't be the only way to perform certain interactions.
We've even usability tested discovering cs menu on a blank area, and it simply
doesn't perform well. 

But have no fear, the issue here isn't that we wouldn't have solutions to this.
:)
Comment 6 Randall Arnold 2008-01-18 02:18:32 UTC
Roope, I don't mean to suggest that individual locking would be the ONLY
option.  Rather, it would be an additional option ALONG WITH a restored global
lock in the main menu.  And it doesn't have to be a context popup to be
useful-- alternatively, a lock/don't lock menu could pop up after every move to
give the user an immediate option.

And as a fellow coder I recognize that the grid suggestion is nontrivial, but
think of the cool iPhone-like factor that would result.  : D
Comment 7 tuukka.tolvanen nokia 2008-01-18 22:55:37 UTC
(the grid bit is kinda offtopic here, but if you look at
~/.osso/hildon-desktop/home-layout.conf and how the applet edges line up,
you'll notice there is a 10px snap.)
Comment 8 Neil MacLeod maemo.org 2008-01-19 07:34:51 UTC
(In reply to comment #7)
> (the grid bit is kinda offtopic here, but if you look at
> ~/.osso/hildon-desktop/home-layout.conf and how the applet edges line up,
> you'll notice there is a 10px snap.)
> 

I personally find this 10px snap too large - I've tried to line up applets with
a narrow gap on the left and right and it's proving next to impossible because
the snap grid causes the applet to move either left or right, resulting in a
bigger gap on one side and no gap on the other! If snap grids are to be used in
future, please allow me to fine tune the snap size to suit *my* requirements
and not those of the Maemo UI developer, or allow me to to temporarily turn off
the snap feature.
Comment 9 Roope Rainisto nokia 2008-01-21 10:14:58 UTC
to comment #8: Well, I would personally disagree there: A setting like "set
snap resolution" is exactly the type of setting that if we would have we would
end up in having hundreds of settings in the system for rather trivial things.
Ideally the snap 10px is something that suits most users most of the time. We
actually iterated that value somewhat and 10px was the best of the alternatives
we tried.
Comment 10 Neil MacLeod maemo.org 2008-01-21 15:02:05 UTC
(In reply to comment #9)
> to comment #8: Well, I would personally disagree there: A setting like "set
> snap resolution" is exactly the type of setting that if we would have we would
> end up in having hundreds of settings in the system for rather trivial things.
> Ideally the snap 10px is something that suits most users most of the time. We
> actually iterated that value somewhat and 10px was the best of the alternatives
> we tried. 
> 
Suitable for most users most of the time, but not all users all of the time -
see the problem here? An aversion to settings will render this device
unsuitable for everyone eventually - you're aiming for the lowest common
denominator and eventually you'll have missed everyone with a device that only
"works" for the Nokia UI designers while pissing off everybody else.

Good luck with this approach, I hadn't realised you were designing this device
for complete idiots!

If the snap could be disabled it would at least allow me to drop applets where
I wanted them placed instead of where the snap grid thinks they should be. Of
course I probably wouldn't be complaining if the snap were 5px as 10px is too
large for me. Of course it were a gconf setting I could change it there and you
wouldn't need to add a precious UI setting which could blow the users mind with
the additional complexity.
Comment 11 Roope Rainisto nokia 2008-01-21 15:20:35 UTC
I don't see a problem with "not suitable for all the users all the time" -
that's an impossible requirement. 

I don't see this issue nearly as black and white as you seem to do. The
question is about providing relevant settings for the user and making judgment
calls over what is actually a relevant setting. Smart designs, when possible,
try to work automatically so that the users do not need to care about
configuring them correctly. You can look at any number of successful products,
also from our competitors, to observe this phenomenon. It is not aiming for the
lowest common denominator, it is aiming for the largest common denominator. 

I fail to see how you can jump from this statement to designing for complete
idiots. A vast majority of users are not "pissed off" from the lack of this
setting. A vast majority of users, I would speculate, would be "pissed off" if
every place of our UI would have dozens of settings for trivial minutiae.

There are hacker-type users on one extreme end and there are couldn't-care-less
type of users on the other end. You cannot please all of them at the same time.
Mass markets are really in the center of the gaussian curve, not at the edges.
For hacker-type users, I would be happy if this would be a gconf setting, but
it's not something that we in the UI design field have a lot of power to
control how the SW implements this feature.
Comment 12 Neil MacLeod maemo.org 2008-01-21 15:47:43 UTC
Imposing a snap grid on users without giving the ability to turn it off is only
going to work for some users. The aversion to providing even this simple option
to turn off the grid seems endemic in the mind set of Nokia who insist that
they are right and users are wrong, users are unable to deal with options and
consequently the device can only be used in the way that Nokia designers think
it should be used.

Smart design is all well and good, but providing a snap system without the
option to turn it off is not smart - it's stupid. Very, very rarely do you see
a snap system in use without the ability to either modify the size of the grid
or disable the grid entirely. Why? Because the designers know and more
importantly appreciate that all users are different and don't try to enforce
their world view on their users.

The 10px problem of itself is not a major issue (although I'd be happier with
5px!) however the aversion to adding an option is an argument that seems to
crop up quite frequently when dealing with Nokia and problems with their
"smart" design so the problems remain and users are left
unhappy/irritated/unsatisfied. And it's this attitude that's beginning to piss
me off, but then I guess I'm one of the hacker types at the extreme of the
curve which means I don't matter, right?
Comment 13 Roope Rainisto nokia 2008-01-21 15:52:14 UTC
Yes, for the specific issue of turning snap on and off, I do remember some
preliminary versions where this feature was included. Since I wasn't the
designer in this particular area, I cannot really now tell why turning snap
on/off was removed from the final version. I would have probably personally
erred on the side of retaining the setting of turning it on/off, but that's
just me. 

All in all, if looking back at the original bug report, there are certainly
issues - several issues - with the current Home functionality and UI approach
that are not satisfactory to us, and this area will develop further.
Comment 14 tuukka.tolvanen nokia 2008-01-21 21:38:02 UTC
A method for placing applets more precisely than practical with a touchscreen
(especially if there were no snap), while working around the snap, is provided
at a reasonable configuration depth, mentioned in comment 7. Sorry about
bringing up the existence of the snap here, clearly it was an unwise
digression.
Comment 15 Randall Arnold 2008-01-21 22:29:13 UTC
Neil's comments just drive home how variable this issue is: I find the snap
increments to be too small, not too large.  For me it's darn near impossible to
line up applet icons because they're so "slippery" due to the (to me) tiny snap
increments.  Just when I think I have something lined up I let go of the stylus
and it slides like a hockey puck.  With LARGER increments this wouldn't
happen-- for ME.

And I'm not saying that to discredit Neil's opinion or experience, which are at
least equally as valid as mine.  It's to point out the variety in user
expectations and experience.

But I defer back to the icon alignment suggestion I made earlier.  If I got an
icon aligned *close* to another, just having a temporary "suggested" snap line
would help.  It would tell me that lifting the stylus would force the moved
icon into alignment with the other.  Beautiful.

And this may sound petty to some, but others find aesthetics to be important. 
People will form opinions of a device based on a quick assessment and I want my
tablet desktop looking sharp.  Remember, we users are walking advertisements
for Nokia! ; )
Comment 16 Roope Rainisto nokia 2008-01-22 16:48:44 UTC
I'd almost say that the snap/alignment issue - the issue is also very
important, but it's slightly outside the scope of this particular bug, which is
about not being able to lock applets in place. 

Snap is tricky also in that aspect that even if we assume that all applets are
boxes that fill all of their edges, the reality really isn't necessarily so: a
developer can easily develop an applet where the bounding box doesn't actually
contain pixels all the way: an edge can be rounded or start inside the bounding
box, snapping to other objects in this case will be funny, because it would
then snap annoyingly to where you don't want it to go. 

Anyway... This bug is assigned, so we agree on this issue and are working on
this. :) Just don't expect an immediate fix...
Comment 17 Harri Haataja 2008-07-17 09:23:48 UTC
I would rather advocate an approach like "tiling window management" for these.

There is no good reason I can see why applets should ever overlap. Blank space
can be arranged by leaving sections blank if really neccessary. Otherwise,
divide the area among the active widgets.

No problems with snaps, movement, "action", overlap etc. Complete lock mode and
a complete move mode (only moves instead of activating widgets) would probably
still be welcome and the exact UI would need some thinking, naturally
Comment 18 Quim Gil nokia 2008-07-21 08:01:11 UTC
Hi, this report appears in the Bug Jar top 10.

Roope, any update on supporting this for Fremantle?

Also, you say the bug is assigned - but it appears unassigned. And the alias
field looks suspicious.
Comment 19 Ryan Abel maemo.org 2008-07-21 08:10:02 UTC
(In reply to comment #18)
> And the alias field looks suspicious.
> 

Seems to be submitted-set. Clearing.
Comment 20 Roope Rainisto nokia 2008-07-28 10:35:01 UTC
Yes, this will come to Fremantle, by default applets will be locked into place.
Comment 21 Roope Rainisto nokia 2008-10-21 16:51:11 UTC
Therefore marking as fixed.
Comment 22 Ryan Abel maemo.org 2008-11-16 20:45:13 UTC
*** Bug 3863 has been marked as a duplicate of this bug. ***
Comment 23 Ryan Abel maemo.org 2008-11-16 20:49:22 UTC
Revising summary to use real terms so it's actually findable with a search. . .
.
Comment 24 rafi 2008-11-17 16:09:19 UTC
Thanks for adding the lock to fremantle.  And not to belabor the point, but is
there any reason not to add a fix to diablo?

I'm looking at the source of hildon-desktop_2.0.18-1fix1.  It seems to me that
you could add a desktop_locked boolean to the item, if not the home object
itself.  And then just add "priv->desktop_locked" to the predicate on lines
928-929 in hildon-desktop-home-item.c

  if (priv->state == HILDON_DESKTOP_HOME_ITEM_STATE_NORMAL &&
      (!priv->click_timeout || priv->destop_locked))


Then, all you would need to do is add the menu option (in my mind under
"applet-settings"), and loop through the children each time that is toggled. 
And if you set the default state to unlocked, most people would never notice
the difference.

Now, I know I could continue to dig through the code and recompile the
hildon-desktop package for myself, but I assume someone more familiar with the
code could in fact make the change in just a few minutes, and build an update
with much less effort than myself.


On a side note for the grid snapping.  I would appreciate a grid which would
optionally appear during move/resize.  And I also like options for snap on/off,
and grid size (certainly this thread demonstrates people have different
preferences).  Of course, I acknowledge that I prefer configurability over
simplicity.  But I do think the more advanced options can be hidden in deeper
advanced user controls, or could be left as hooks to be exposed by installing a
plugin.
Comment 25 Andre Klapper maemo.org 2008-11-17 16:21:36 UTC
(In reply to comment #24)
> Thanks for adding the lock to fremantle.  And not to belabor the point, but is
> there any reason not to add a fix to diablo?

Complete and unexpected change of behaviour? :)
I expect lots of "I can't move my applets anymore, something is broken"
reports.
Comment 26 Roope Rainisto nokia 2008-11-17 16:27:26 UTC
It's the same question as for any improvement we are making... In this
particular case it's easier, Home is going through a larger improvement chain,
we cannot separate this particular improvement over certain other improvements
we have done. 

(Of course I'm not saying that doing this for the Diablo codebase would be huge
work, but for Fremantle, Home isn't completely the same as in Diablo.)
Comment 27 rafi 2008-11-17 17:37:44 UTC
> Complete and unexpected change of behaviour?  :) 
> I expect lots of "I can't move my applets anymore, something is broken"
> reports.

Default to unlocked, and I guess popup a warning, if you think it would really
make a difference and wouldn't add more than a few lines of code.


As for fremantle vs diablo.  I take it fremantle is still 5-6 months away, at
least for normal users.  That's a lot of extra desktop cleanups (yes, I made
the layout file read only, but I don't actually reboot nearly as often as
things get moved around).  :)

Anyway, since you all are busy writing the more interesting stuff, if I send in
a patch, would someone review, assimilate and update the repo?


Will the Fremantle home work with Diablo, or does it depend on too much that's
not there?
Comment 28 Andre Klapper maemo.org 2008-11-17 17:41:58 UTC
I DO know that the Desktop software team concentrates on Fremantle and as far
as I know by default only accepts patches for major and critical issues.
If you have a patch handy already, it can't hurt to attach it here to make it
available for other interested users though.
Share it, it's open source! :)
Comment 29 Neil MacLeod maemo.org 2008-11-17 18:02:07 UTC
(In reply to comment #25)
> Complete and unexpected change of behaviour? :)
> I expect lots of "I can't move my applets anymore, something is broken"
> reports.

If the SSU/FIASCO update contained a detailed changelog describing the change
in Home page applet behaviour then where is the problem?

The only problem seems to be that Nokia are completely incapable of generating
suitable changelogs with each release... don't use that as an excuse for not
fixing stuff please!

Anyway, at least that's one more bug with a huge number of votes against it
neatly brushed under the carpet! Will there be any point raising then voting
for bugs at all soon?? ;-)
Comment 30 Andre Klapper maemo.org 2008-11-17 18:15:08 UTC
(In reply to comment #29)
> (In reply to comment #25)
> > Complete and unexpected change of behaviour? :)
> > I expect lots of "I can't move my applets anymore, something is broken"
> > reports.
> 
> If the SSU/FIASCO update contained a detailed changelog describing the change
> in Home page applet behaviour then where is the problem?

How many users will actually read that ChangeLog? 10%? 15%? How many will click
it away without reading and scrolling through that list?
(Note that I'm not arguing against providing a ChangeLog here, though you can
always query Maemo Bugzilla for bugs with a specific Target Milestone set.)
Comment 31 Neil MacLeod maemo.org 2008-11-17 19:04:38 UTC
(In reply to comment #30)
> How many users will actually read that ChangeLog? 10%? 15%? How many will click
> it away without reading and scrolling through that list?
> (Note that I'm not arguing against providing a ChangeLog here, though you can
> always query Maemo Bugzilla for bugs with a specific Target Milestone set.)

Depends how well it's publicised and how accurate it is - why not include a
link on the firmware download page, or force the user to review the changelog
in the Application Manager etc. even if it's just a high level version (with a
detailed, cross-referenced version available via a link).

Granted readership is not going to be 100%, but if Nokia a) provide a changelog
and b) tghen provide the mechanism(s) to ensure it is read by users then it
will be closer to 100% than 10%.

However judging by your previous comment 25 you seem to be suggesting that
fixing basic, horrible UI regression bugs like this shouldn't happen because
users would be "confused" - I wonder how many users were confused (no, actually
really annoyed and p1ssed off - 65 at least it would seem!) after this bug
tipped up in Diablo particularly when you consider that users had been able to
lock applets in all OSes up to and including Chinook without any issues (and
that's why this bug is really a regression, and not an enhancement)?

Changing behaviour between Chinook and Diablo without any notice did not fail
to stop Nokia from implementing this brain dead "feature" then, so I don't buy
your argument for not fixing what Nokia broke with Diablo. Your comment seems
to suggest that UI bugs won't be fixed mid-release even if it's the right thing
to do, which I have to say is disappointing. And if a bug with 65 votes isn't
considered "major" I don't know what is (maybe one with 90?) ;)
Comment 32 Andre Klapper maemo.org 2008-11-17 19:20:02 UTC
(In reply to comment #31)
> However judging by your previous comment 25 you seem to be suggesting that
> fixing basic, horrible UI regression bugs like this shouldn't happen because
> users would be "confused" 

You're generalizing, and you know about that...

> I wonder how many users were confused (no, actually
> really annoyed and p1ssed off - 65 at least it would seem!) after this bug
> tipped up in Diablo particularly when you consider that users had been able to
> lock applets in all OSes up to and including Chinook without any issues (and
> that's why this bug is really a regression, and not an enhancement)?

If it worked in Chinook, why was this bug filed in December 2007 and not in
June 2008? You meant Bora. ;-)
To get serious again:
Sorry, I have never used Bora, and your last comment is the first time it was
ever mentioned **clearly** here that this report is about a regression. I
wasn't aware of that, so please reconsider my argumentation of changing the
user interaction behaviour in a minor update under that aspect.
Comment 33 Neil MacLeod maemo.org 2008-11-17 19:41:06 UTC
(In reply to comment #32)
> You're generalizing, and you know about that...

I think we both are, to be honest.

> If it worked in Chinook, why was this bug filed in December 2007 and not in
> June 2008? You meant Bora. ;-)

You are correct and I am, er, a confused user! ;-)

The ability to lock desktop applets was available in the UI all the way up to
and including OS2007 (ie. Bora/Maemo 3.0-3.2) and became broken in
OS2008/Chinook/Maemo 4.0 and has remained broken in OS2008/Diablo/Maemo 4.1.

Too many code names... :)

> To get serious again:
> Sorry, I have never used Bora, and your last comment is the first time it was
> ever mentioned **clearly** here that this report is about a regression.

No need to apologise. :)

> I
> wasn't aware of that, so please reconsider my argumentation of changing the
> user interaction behaviour in a minor update under that aspect.

To be clear on this - are you saying that in light of my assertion that this is
a regression (although some within Nokia might argue it is intentional/by
design/as per the spec/yada yada despite being blatent poor design) do you mean
it might be fixed in a future Diablo update?
Comment 34 Andre Klapper maemo.org 2008-11-17 21:45:11 UTC
(In reply to comment #33)
> To be clear on this - are you saying that in light of my assertion that this is
> a regression (although some within Nokia might argue it is intentional/by
> design/as per the spec/yada yada despite being blatent poor design) do you mean
> it might be fixed in a future Diablo update?

From my POV (having had similar discussions in other projects I've been working
on) it might make it a bit more easier, but from a code integration and testing
point of view I don't expect Nokia to "happily" introduce such a big change
that late in the Diablo release cycle.
Please note that I don't and can't speak for Nokia here - maybe Quim (CC'ed)
might have a direct discussion with the corresponding manager and point to the
65 votes that this bug has. :-/
Comment 35 Quim Gil nokia 2008-11-17 22:38:02 UTC
Hi,

The jump from Bora to Chinook is not considered a regression. In Bora and
before applets were locked, and there was an editing option to move them around
with a non-simple UI. In Chinook this was improved: moving applets was easy -
but according to this report here *too* easy.

And as Roope explains it was agreed that something else needed to be done, and
is being done in Fremantle. The effort to implement this enhancement is part of
a whole home revamp. We rather concentrate our resources making that revamp
successful.

Sorry, an intermediate backport to Diablo is definitely not in our plans. Once
you see the Fremantle home and code there will be more ground for this
discussion.
Comment 36 Neil MacLeod maemo.org 2008-11-17 22:47:47 UTC
(In reply to comment #34)
> but from a code integration and testing
> point of view I don't expect Nokia to "happily" introduce such a big change
> that late in the Diablo release cycle.

Which is understandable, but it's so unfortunate that bugs such as this are
left/ignored/overlooked for almost a year which renders this type of excuse for
not fixing bugs all too common in Maemo Bugzilla.

> Please note that I don't and can't speak for Nokia here - maybe Quim (CC'ed)
> might have a direct discussion with the corresponding manager and point to the
> 65 votes that this bug has. :-/
> 

I understand that - and more's the pity! ;-)
Comment 37 Neil MacLeod maemo.org 2008-11-17 23:04:12 UTC
(In reply to comment #35)
> Hi,
> 
> We rather concentrate our resources making that revamp
> successful.
> 
> Sorry, an intermediate backport to Diablo is definitely not in our plans. Once
> you see the Fremantle home and code there will be more ground for this
> discussion.
> 

Quim - thanks for popping in and clarifying the situation.

OK - so this bug is a WONTFIX. End of.

Now a related issue - how did this happen? Why is it that bugs such as this are
being closed as WONTFIX almost a full 12 months after being opened, simply
because the developers are now focused on the next-big-thing which won't be
shipping for another 6+ months, leaving the current software to stagnate as it
is, warts and all? This has been the trend since the beginning, can't Nokia
devote someone to maintenance and have them work through the annoying, trivial
bugs and ship them via SSU? What was the point of SSU - did I miss it? In a
similar vein, what is the point of raising bugs if they're allowed to rot until
they become irrelevant? And this one had 65 votes!! :0

Can we get some sort of commitment that going forward, with the release of
Fremantle and the apparent increased willingness of Nokia to include the
community in early testing, minor/irritating/ridiculous/insane UI bugs such as
this will be fixed sooner rather than later/never-at-all? If this situation is
allowed to continue once Fremantle is released (ie. Fremantle bugs are never
fixed as everyone is now working on Harmattan, guaranteeing generally poor
software quality in the long run) then I have to wonder if the Nokia Tablets
are destined to remain as mere curiosities rather than serious tools.

Whatever happened to release early, release often? :)
Comment 38 Ryan Abel maemo.org 2008-11-17 23:19:54 UTC
(In reply to comment #37)
> OK - so this bug is a WONTFIX. End of.
> 

No, this is FIXED. Just because it isn't fixed for the release it was filed for
doesn't mean it wasn't fixed. :)
Comment 39 kenneth 2008-11-17 23:23:20 UTC
i think what worries a lot of people when it comes to "fixed in fremantle" is
this:

will fremantle be available on existing device, or will they have to get a new
device to make use of the refinements that fremantle provides over existing
software?
Comment 40 Andre Klapper maemo.org 2008-11-17 23:24:33 UTC
(In reply to comment #37)
> OK - so this bug is a WONTFIX. End of.

For the current stable Diablo series: Yes, as this cannot easily be ported
back.
For the next major release Fremantle this bug is FIXED.

> Now a related issue - how did this happen? Why is it that bugs such as this are
> being closed as WONTFIX almost a full 12 months after being opened, simply
> because the developers are now focused on the next-big-thing which won't be
> shipping for another 6+ months, leaving the current software to stagnate as it
> is, warts and all?

I wouldn't call 76 fixed Maemo bugs (and probably a lot more non-public issues)
since the first Diablo release 4.2008.23-14 "stagnation", but I understand the
point you make. It's just that a company does not have unlimited manpower and
ressources I guess, so you have to concentrate and make decisions. And as far
as I know the source code is available too, so you're always invited. :)

> Can we get some sort of commitment that going forward, with the release of
> Fremantle and the apparent increased willingness of Nokia to include the
> community in early testing, minor/irritating/ridiculous/insane UI bugs such as
> this will be fixed sooner rather than later/never-at-all?

That's what I hope to do, though help in triaging the incoming and existing bug
reports is always welcome. Just get involved.

Anyway, this bug report is not a good place for discussing this and triggers a
bunch of mail to those originally only interested in this particular issue.
Let's move this to e.g
https://wiki.maemo.org/Task:Getting_Nokia_involved_in_bugs.maemo.org and its
discussion page or the famous bug 630...
Comment 41 rafi 2008-11-18 01:41:39 UTC
Created an attachment (id=1038) [details]
initial attempt at adding a drag lock

This patch is not intended to be a proper fix, rather a starting point.

I've added a state bit to each home-item (applet) for drag lock.  And added a
check menu item to the home menu.  When that menu item is triggered it sends
the new state to all currently activated applets.

Issues:
1.  no state is stored
2.  applets that aren't active don't get the lock when they are activated.

On the up side, for those of us who don't modify the desktop very often and
rarely reboot, this might just be enough until the next release.

Please comment/improve.
Comment 42 Ryan Abel maemo.org 2008-11-18 01:56:13 UTC
(In reply to comment #35)
> And as Roope explains it was agreed that something else needed to be done, and
> is being done in Fremantle. The effort to implement this enhancement is part of
> a whole home revamp. We rather concentrate our resources making that revamp
> successful.
> 

Alright, if Nokia wont implement it, would it be unreasonable to ask for a
helping hand here and there with a community patch and for Nokia to ship it
with hildon-desktop once it's complete?
Comment 43 Ryan Abel maemo.org 2008-11-18 02:04:56 UTC
(In reply to comment #42)
> (In reply to comment #35)
> > And as Roope explains it was agreed that something else needed to be done, and
> > is being done in Fremantle. The effort to implement this enhancement is part of
> > a whole home revamp. We rather concentrate our resources making that revamp
> > successful.
> > 
> 
> Alright, if Nokia wont implement it, would it be unreasonable to ask for a
> helping hand here and there with a community patch and for Nokia to ship it
> with hildon-desktop once it's complete?
> 

I should add that although I can certainly understand Nokia not wanting to
invest additional coding time towards a dead platform except in the cases of
critical bugs, it doesn't seem unreasonable to expect that they would at least
be willing to accept and ship patches where the community does all the heavy
lifting and Nokia only needs to spend 5 minutes applying a patch (bug #3470 for
example), especially as the reason for most of these bugs going unfixed is
_ENTIRELY_ Nokia's fault (bugs simply left ignored until the window for Diablo
fixes closed, then WONTFIXed).

Either that, or do what needs to be done to get continued Diablo support into
community hands. . . . Any other choice (leaving it permanently WONTFIXed for
Diablo, even if there's a perfectly good community patch available) is simply
user- and community-hostile.
Comment 44 rafi 2008-11-18 02:19:51 UTC
> Alright, if Nokia wont implement it, would it be unreasonable to ask for a
> helping hand here and there with a community patch and for Nokia to ship it
> with hildon-desktop once it's complete?

On that note, I'm at a loss as to how to build a deb from the modified source
in scratchbox.  dpkg-buildpackage is saying a few weird things.
Comment 45 Faheem Pervez maemo.org 2008-11-18 18:15:24 UTC
(In reply to comment #44)
> > Alright, if Nokia wont implement it, would it be unreasonable to ask for a
> > helping hand here and there with a community patch and for Nokia to ship it
> > with hildon-desktop once it's complete?
> 
> On that note, I'm at a loss as to how to build a deb from the modified source
> in scratchbox.  dpkg-buildpackage is saying a few weird things.
> 

Applied your patch fine and I built a deb fine (are you doing this on a clean
source tree?).

I "dpkg -i'ed" the 3 relevant deb files that were created and rebooted the
tablet and when restarted, I got a nice drag lock function which works very
well for me.

Thank you for taking the time to do what Nokia are evidently too lazy to do
(and it will be fixed in Fremantle IS NOT an answer. The people with this
problem is people NOW with tablets that run diablo).
Comment 46 aimjournals 2008-11-19 03:22:34 UTC
(In reply to comment #45)
> Applied your patch fine and I built a deb fine (are you doing this on a clean
> source tree?).
> 
Could you attach the debs here or upload them somewhere?  There are a lot of
people (myself included) that would like this but are either too lazy to set
everything up, or not technically able to.
Comment 47 rafi 2008-11-19 03:55:25 UTC
Created an attachment (id=1039) [details]
1/3 debs

Beware, try this at your own risk
Comment 48 rafi 2008-11-19 03:56:05 UTC
Created an attachment (id=1040) [details]
2/3
Comment 49 rafi 2008-11-19 03:56:48 UTC
Created an attachment (id=1041) [details]
3/3
Comment 50 rafi 2008-11-19 04:02:07 UTC
Created an attachment (id=1042) [details]
tarbal with 10 debs, including the dev and dbg versions.
Comment 51 rafi 2008-11-19 04:07:34 UTC
> Could you attach the debs here or upload them somewhere?  There are a lot of
> people (myself included) that would like this but are either too lazy to set
> everything up, or not technically able to.

Just be sure you'll be able to ssh in after a reboot.  If anything goes wrong,
you will not get much of an interface on the tablet itself.

If you run into trouble getting this to work and solve it, please make sure you
post what went wrong, and what fixed it.  I unfortunately didn't pay close
enough attention when I tried it the first time and failed.

Also.  Reboot the device after the installation.  I tried just restarting the
hildon-desktop process and it reboots anyway.  Probably better to shutdown a
little more gracefully.
Comment 52 aimjournals 2008-11-19 04:27:05 UTC
(In reply to comment #51)
> If you run into trouble getting this to work and solve it, please make sure you
> post what went wrong, and what fixed it.  I unfortunately didn't pay close
> enough attention when I tried it the first time and failed.

Thank you!  Nothing went wrong in the installation here.  I see the new "Drag
Lock" item in the menu, and it functions almost as it should!  The only problem
I found is that a tap and drag is interpreted as a tap, instead of as nothing. 
This only creates some small problems: eg, when dragging omweather when drag
lock is on, the detailed weather still opens.  Seems to me that drags should
have their tap ignored.
Comment 53 Quim Gil nokia 2008-11-19 11:29:07 UTC
Grrrr

I thought I had posted a comment here yesterday but now I see it wasn't posted,
indirectly caused by my own Bug 3864 . It was a long and thoughtful one....

At least in this case you can't say that Nokia ignored the bug, when the first
person to comment was a Nokia UI designer a couple of weeks after it was
submitted. Roope has been following here the discussion. Then, he is not alone
in this world and the decision was to improve this in Fremantle while keeping
things as they are in Diablo.

> Nokia only needs to spend 5 minutes applying a patch

Applying patches is not a 5 minute task even in pure volunteering open source
development, leave alone in corporate processes. For instance, purely in the
technical side the patches submitted here include an addition of a UI string
that would need to be translated. Then translations, UI change and code would
need to be tested and accepted before shipping them as part of the official
release.

But you can avoid all this just by handling a community variant, and this is
why we better invest our time working on
http://wiki.maemo.org/Objective:Maemo_variants instead of fighting with the
Diablo program accepting patches for non-critical bugs and features.
Comment 54 rafi 2008-11-19 17:10:16 UTC
Created an attachment (id=1043) [details]
Little cleanup of the drag lock behavior.

Moved the drag lock trap to the part of the code that actually moves and
resizes.  This seems to improve the sending click behavior.  If it would have
been a drag or move, the action is now discarded.
Comment 55 rafi 2008-11-19 17:12:11 UTC
Created an attachment (id=1044) [details]
Binaries for people to try drag lock v2
Comment 56 rafi 2008-11-19 19:14:53 UTC
Created an attachment (id=1045) [details]
made drag_lock a static field so all applets have consistent state

By moving the drag_lock field to a static for the class, I've eliminated the
problem with applets that are unlocked when they are enabled.
Comment 57 rafi 2008-11-19 19:14:58 UTC
Created an attachment (id=1046) [details]
made drag_lock a static field so all applets have consistent state

By moving the drag_lock field to a static for the class, I've eliminated the
problem with applets that are unlocked when they are enabled.
Comment 58 rafi 2008-11-19 19:37:53 UTC
I think I've put in about as much time as I have at the moment for this.  If
someone wants the tarball for that last version, just ask.

Is there any serious interest in adding support for individual lock controls
(so you could say leave omweather locked so you don't screw it up when
arranging other things)?  I'd be willing to go as far as the basic support, but
I'm more willing to edit the lock state in the home-layout.conf than trying to
figure out a gui control.


If anyone can help with storing the global lock state, I'd appreciate help with
that.  My first attempt was getting convoluted, and I've decided to shelve it
for now.
Comment 59 timeless 2008-11-20 03:20:06 UTC
(From update of attachment 1046 [details])
just a note, the code you're patching doesn't seem to use tabs, on occasion you
do, if i were upstream (and i'm mozilla, not hildon), i'd ask you to replace
the tabs.

printfs of course shouldn't be in the final product. Either ifdef DEBUG or
ifdef DEBUG_username.

you're going to need to replace 'Drag Lock' with proper _(...) macros

Lacking a reasonable identifier, i'd probably use this one:
http://mxr.maemo.org/diablo/search?string=keyboard+label%7CScroll_Lock&find=%5C.po%24

Alternatively, maemo.org is appealing to localizers for help w/ new package
category localizations, you could try reaching out to the same group.

FWIW, internally I was able to track down nativeish speakers for a new string
in about 4 hours of running around one floor. Then I lost my strings. In about
two days of using an open source community, I had replacements. So it's
definitely possible. There's also a fairly comprehensive string table available
from microsoft covering many common strings and dozens of languages.
Comment 60 Faheem Pervez maemo.org 2008-11-20 09:43:25 UTC
(In reply to comment #59)
> 
> you're going to need to replace 'Drag Lock' with proper _(...) macros
>  

Is it really worth wasting time to localise the string for a patch that Nokia
most likely (and by most likely, I'd bet my right arm) won't include?
Comment 61 Ryan Abel maemo.org 2008-11-20 12:24:51 UTC
(In reply to comment #60)
> (In reply to comment #59)
> > 
> > you're going to need to replace 'Drag Lock' with proper _(...) macros
> >  
> 
> Is it really worth wasting time to localise the string for a patch that Nokia
> most likely (and by most likely, I'd bet my right arm) won't include?
> 

Well, at the very least you'd be doing the Right Thing for non-English users
who want to use the .deb, and if a Community variety DOES get going. . . .
Comment 62 Neil MacLeod maemo.org 2008-11-20 12:43:28 UTC
Is the Microsoft list that timeless refers to publicly available?

If translation is an issue, how about an image (open/close padlock?) as an
alternative to words?

And if we do go the whole hog of translating every community application/patch,
how best to source submissions in different languages - ITt? Wiki? Bugzilla?
I'd guess ITt has the widest and most active audience - perhaps a special forum
designed solely for this purpose would be a good idea for the future...
Comment 63 Andre Klapper maemo.org 2008-11-20 12:47:35 UTC
In general I'd recommend http://en.open-tran.eu/whatfor.html instead of trying
to find Microsoft glossaries online. :-P
Comment 64 rafi 2008-11-20 19:33:18 UTC
> just a note, the code you're patching doesn't seem to use tabs, on occasion you
> do, if i were upstream (and i'm mozilla, not hildon), i'd ask you to replace
> the tabs.
Yeah, kinda caught that on a patch to another project.  Just had my vimrc
configured for something silly, don't even remember why anymore.

> printfs of course shouldn't be in the final product. Either ifdef DEBUG or
> ifdef DEBUG_username.
Thanks for catching that, just forgot wrap or pull that.

> you're going to need to replace 'Drag Lock' with proper _(...) macros
Ok, I generally tend to shy away from gui coding, and frankly have never
touched gtk or internationalization before.  I was wondering what was up with
all those underscore wrapped strings.  Can you point us to a reference that
explains them?  Looking at hd-home-l10n.h, it seems nokia used _MAD().  And
what's more, they left in:
#define HH_MENU_EDIT_LAYOUT         _MAD("home_me_edit_layout")/*NOLOC*/
from the old days.  Maybe I should just use that.  Though the comment "NOLOC"
is concerning.  I don't even know where to find the translation tables.

Thank you for the advice.  We should appreciate and not complain about positive
critique, as we all make careless mistakes, and we can all stand to become
better programmers.

For now, I think I'm still staying hands off for a bit.  So now would be a good
time for someone else to add to the patch, or for people to discuss what can be
done better.  I'll certainly make sure to catch up before I look at the code
again.
Comment 65 Andre Klapper maemo.org 2009-01-13 19:46:30 UTC
*** Bug 4000 has been marked as a duplicate of this bug. ***
Comment 66 Andre Klapper maemo.org 2009-04-28 15:34:59 UTC
Setting Target Milestone to Fremantle SDK beta.
Comment 67 timeless 2009-07-20 10:48:52 UTC
it sure *used* to be online, i know that's how *i* got it.

http://www.microsoft.com/globaldev/tools/MILSGlossary.mspx it looks like it's
now limited to MSDN/TechNet :(

If someone wants access to a dated version, I can probably find someone who
still has a copy from when it was less restricted....
Comment 68 Faheem Pervez maemo.org 2009-07-20 11:04:15 UTC
(In reply to comment #58)
> If anyone can help with storing the global lock state, I'd appreciate help with
> that.  My first attempt was getting convoluted, and I've decided to shelve it
> for now.
> 

I've extended your patch to do just this:
http://qwerty12.qole.org/hildon-desktop/source/hildon-desktop_2.0.18-1fix1.diff.gz
Comment 69 Daniel Martin Yerga 2009-08-05 17:07:20 UTC
*** Bug 4880 has been marked as a duplicate of this bug. ***
Comment 70 Lucas Maneos 2009-10-22 07:56:48 UTC
Marking patches of interest to Diablo (Maemo4) community updates, please excuse
the noise.