Notices

Also UI is not ready for portrait mode - application does not re-arrange due to lack of Qt design knowledge from it's author.

After some of my UI changes portrait mode is working - usable thing to have when you want to sort items.

Too bad that I had to recreate whole UI from scratch ;(

Very good feature Hrw.
When will this update be ready in the repository?

Every time I move an app into a folder ApMefor freezes & I have to kill it to be able to get back to the desktop. Just me? TX

Zentenario: no idea. Need to get working version first, then contact author and sent patches.

I do not want to fork it under new name.

New changes, new screenshots.

- removed TabWidget
- merged Create/Edit & Delete tabs into Folders window (need to stack it)
- enabled auto rotation - only handy for sorting applications

Todo:

- menu option for deactivation
- on start checking for activation

I want to make ApMeFo to check on start was it activated or not. If not then show warning + "Activate" button. If was activated then no such action just go into UI. Deactivation possible by menu option.

What do you think?

@Hrw
great changes! could you publish the patched/new files here so that we don't have to wait for an official update?

For me personally I just miss two features. but I think they are hard to be implementad:
* Change order of icons at root screen (the first screen with prog icons)
* Abillity to have shortcuts also in root and in a folder (I know this can be done by copieng the desktop file...)

Not sure I agree at all. Perhaps I'm not getting what you mean, but that seems like an entirely personal-preference matter.

Fair enough. I'd agree with that. Rather, to me it's not awkward, but it could certainly be improved.

I disagree there. It is only awkward for the first few minutes if you're not used to seeing other programs with similar conventions, and have to figure out that you should click the select button and the box is the name. Once you press the select button, it's vey intuitive, because it's just a list of the pictures. Can't really get more intuitive than that.

Furthermore, space? We don't really have an issue of space in the ui as is. Also, just because most people don't want or can't use the icon paths and names automatically, doesn't mean just having the option is bad. Some people do have enough experience fiddling with the file system or just looking around in there to be able to use the text box, because maybe they DO remember the name of the icon. But I DO like the idea of showing the picture of the icon, and I say that should be implemented. What I would suggest to / request from Hrw is that if you add the picture, (say, where the text box is now), put the textbox under it - ideally made to show the path of the file instead of just the name (does the current ApMeFo have the ability to use icons from anywhere, or does it have to be one folder - I'm not knowledgable how the underlying code works).

That said, as it is right now, so long as the list still shows the name of the icon, I suppose having the icon itself shown instead of its file name would be an improvement. Though I recommend both (and if I had the coding experience to do it, I would, but there I am lacking).

Eh, the box is grayed out. I thought it was pretty self apparent. Also, it gives you an extra layer of certainty that you selcted the right thing. There were plenty of times when I could've sworn I selected an icon from the list, only to find out I accidentally selected something else right next to it, or had it glitch and select an entirely unrelated icon. With icons this is fine becuase you can see the name of it, or (as proposed) the picture or both. But with folders if you don't have that box there you don't really have a way to see what you're deleting.

I agree, but if this is implemented, I think it makes having the text box in the above point for icon selection when editing/creating folders all the more necessary. Granted, not literally necessary, but I think having at least one place that tells you what the file name of the image you're using is is a pretty good feature to have. I don't really see how it impedes intuitiveness at all, or usability, especially when you have the select buttons, especially with the above suggested changes. I think there's enough use cases when someone might want to know the name or path of the icon file without knowing enough about where to find the relevant directories or .menu/.desktop config files to make completely cutting out the icon filename from the UI unjustified. But, if I had to pick, I'd say leave it in the folder editing creating menu and implement the grid of icons you recommend for icon selection. (though the question is how easy IS icon grid implementation in this UI? It may just be to ridiculous of a coding pain in the anal region.)

I think this has to do with how the app works. It has to first select the right .menu and/or .desktop (not sure what the details are) file to make the changes to. But, this should be automatable and I agree, there is a certain redundancy to it. I never minded, but I probably wouldn't mind any other alternative. though, on second thought, some of it makes perfect sense. someone might be mid updating their folder (therein being the first 'selecting'), shuffling a bunch of stuff around, then decide they don't want to keep the changes, or want to make a different set of changes, but starting over from what they had would be more effective then moving/adding/deleting apps to get there from where they are now. Is it really better to have every change saved as you make it to the folder you're updating instead of having an 'update' button? That's not redundancy, that, to me, is common sense. Unless our goal is a minimalistic UI instead of a more functional one.

Contemplating the other possibilities: I think folder creation/editing is basically the same thing. I do agree on deleting, I suppose, though you're ultimately doing the same thing, as the already does: Select folder for deletion, press delete button vs Select folder for deletion, press yes to pop up window (the only difference being you don't get a pop-up menu if the folder is empty - which I personally don't mind but some people might want to be asked for confirmation even if the folder's empty - ideally there'd be a settings option for this). Anyway, it COULD be more convenient if you make a delete button instead of a delete tab/page/section, which then takes you straight to selection list, which then lets you delete it. Alternatively, you have a delete button in the folder editing/updating menu (Could these be combined - the folder icon and apps in it, + delete button, in the same menu, and seperate bits for folder create and activate/deactivate?). Anyway, if you do that, then combined with pop up message for confirm/cancel delete would be both more efficient and more convenient otherwise.

Agreed. That would be useful, but I just didn't think of it as part of the UI.

agreed with the parenthetical one. I myself would probably never use the disable option, but it's worth having, I think, for those usrs who want it. Not so sure that would make havin it edit the existing hildon.menu a possibility, without doing more voodoo just to have it save the existing one as the "disable" revert point. Unless you mean it should coy the hildon.menu arrangement to start with, but then still edit it's own folders. *shrug*

Meanwhile, I'm liking the direction that Hrw seems to be taking. The main reason I asked at all was worry because of the possibility of UI changes I would significantly dislike being planned, but it's going well so far.

Yes, the original author Nathraiben seems to be missing in action.

The UI changes are looking good and promising. But the really important thing we should try to change is explained in this post: Link
But I don't understand what she is trying to explain. And perhaps its dangerous to try to change this parts without understanding all details of the system...

Many thanks Avis for this discoverment that works. In fact it's quite funny for me that gas-balls application and I don't feel like removing it.

Could you tell where I can find the folder where that file gas-balls.desktop is? I'm unable to locate it (I canot find any "gas-balls" folder even in hidden folders).

Thanks in advance.