[Kindle] Unified Application Launcher. KUAL

[stepk]

Originally Posted by DuckieTigger

I tend to agree to that, officially.

Unofficially? Yes nested menus are possible....
Tested successfully on PW 5.3.3 with KUAL 0.3.2 and kterm running through KUAL.

Hey DuckieTigger, that's ingenious! I like it, but I wonder if that's the kind of "nested menu" that people have in mind when they ask for nested menus. I presume that they mean nested in the sense of a dynamic menu, like yfan lu's graphical menu, where you can visit the whole menu structure without interrupting the navigation. Anyhow, your hack has value, for instance if someone wants to temporarily hide all entries but the ones that are "needed for the job". Thanks for sharing your idea.

[twobob]

Originally Posted by stepk

Hey DuckieTigger, that's ingenious! I like it, but I wonder if that's the kind of "nested menu" that people have in mind when they ask for nested menus. I presume that they mean nested in the sense of a dynamic menu, like yfan lu's graphical menu, where you can visit the whole menu structure without interrupting the navigation. Anyhow, your hack has value, for instance if someone wants to temporarily hide all entries but the ones that are "needed for the job". Thanks for sharing your idea.

Yeah. I liked his idea too...

(we really have to look at the non suiciding option RSN!!!) and possibly DRILL DOWN into group? with a RETURN button?

whats your thoughts on that.

[DuckieTigger]

Originally Posted by twobob

Yeah. I liked his idea too...

(we really have to look at the non suiciding option RSN!!!) and possibly DRILL DOWN into group? with a RETURN button?

whats your thoughts on that.

My thought is that a dynamic menu would be great. I am afraid that you will need to change the internal datastructure and add functionality to the parser.

Stepk, look again, I am not only showing a subset of what is needed, but a set of buttons previously NOT shown at all. and everything happens without overwriting any files - purely on OS level.

[DuckieTigger]

Just had a possibly simple idea on how to implement sub-sub-menues. It only requires minor adjustments and a non-suicidal button.

• add a optional tag to config.xml called "do-not-recurse" with a name for the button to open sub-menu
• when parser reads a do-not-recurse, ignore all sub-directories with further config.xml, create a button with the sub-menu name that will invoke clearing of all buttons in KUAL, reinvoking the parser starting at the directory the config.xml sat in
• when parser is invoked from a certain directory other than /mnt/us/extensions do 2 things: ignore the config.xml in the start-directory, only recurse down. Add a button at the top "MAIN" that will clear the buttons and reinvoke the parser at /mnt/us/extensions.

Minimal changes, only one tag and name added to config.xml. Extension developer does not need to know how to clear buttons (as the command for MAIN button in sub-menu and the button to open the sub-menu will be created by parser). It will work recursive, so sub-sub-sub-menues can easily be done.

Not completely elegant: the only way to get out of sub-menu is to go back to top hierarchy. The good though? No need to keep track of how you got to a sub-menu - it is always a sub-menu when not started from /mnt/us/extensions.

Things that would be nice: non-suicidal buttons that will keep you in a submenu, or remember which sub-menu you last used.

edit: Of course this is not the dynamic menu either. Problems may arise when sorting is concerned - and your internal data structure. Pure dynamic you have to ensure they stay grouped and visibly different. You would not want to explode a submenu and have them mixed in with the other buttons? No restart of KUAL needed, so it is kind of dynamic - my hack requires it, because after all it is a hack.

[stepk]

Originally Posted by DuckieTigger

My thought is that a dynamic menu would be great. I am afraid that you will need to change the internal datastructure and add functionality to the parser.

Stepk, look again, I am not only showing a subset of what is needed, but a set of buttons previously NOT shown at all. and everything happens without overwriting any files - purely on OS level.

DuckieTigger, yes I saw what your hack can do. I just described it from a "why, would a user need it?" point of view, i.e. "to focus on a task" (I know the task could include a new set of buttons with your method).

Re dynamic menus, I don't think the parser needs more code, but the java code does for sure - if nothing else to display a dynamic menu.

Originally Posted by twobob

Yeah. I liked his idea too...

(we really have to look at the non suiciding option RSN!!!) and possibly DRILL DOWN into group? with a RETURN button?

whats your thoughts on that.

Non suiciding option should be easy as a user-controlled flag in menu.json.

Drilling down into a submenu + return button sounds within reach of the current code set with a few controlled additions, (goes into thinking...)

[stepk]

Thanks, food for thought. However, I think this would be difficult to do with the current code base, due to the way the kindlet invokes the parser - one shot, control doesn't go back and forth, data is passed back in a single stream
Thread history: I learned the hard way that KUAL development likes a simple incremental path.

Q for all: is a two-level nested menu, that is no sub-sub-... menus, just sub-menu, not enough for the vast majority of kindle use cases?

Originally Posted by DuckieTigger

Just had a possibly simple idea on how to implement sub-sub-menues. It only requires minor adjustments and a non-suicidal button.

• add a optional tag to config.xml called "do-not-recurse" with a name for the button to open sub-menu
• when parser reads a do-not-recurse, ignore all sub-directories with further config.xml, create a button with the sub-menu name that will invoke clearing of all buttons in KUAL, reinvoking the parser starting at the directory the config.xml sat in
• when parser is invoked from a certain directory other than /mnt/us/extensions do 2 things: ignore the config.xml in the start-directory, only recurse down. Add a button at the top "MAIN" that will clear the buttons and reinvoke the parser at /mnt/us/extensions.

Minimal changes, only one tag and name added to config.xml. Extension developer does not need to know how to clear buttons (as the command for MAIN button in sub-menu and the button to open the sub-menu will be created by parser). It will work recursive, so sub-sub-sub-menues can easily be done.

Not completely elegant: the only way to get out of sub-menu is to go back to top hierarchy. The good though? No need to keep track of how you got to a sub-menu - it is always a sub-menu when not started from /mnt/us/extensions.

Things that would be nice: non-suicidal buttons that will keep you in a submenu, or remember which sub-menu you last used.

edit: Of course this is not the dynamic menu either. Problems may arise when sorting is concerned - and your internal data structure. Pure dynamic you have to ensure they stay grouped and visibly different. You would not want to explode a submenu and have them mixed in with the other buttons? No restart of KUAL needed, so it is kind of dynamic - my hack requires it, because after all it is a hack.

[DuckieTigger]

Originally Posted by stepk

Thanks, food for thought. However, I think this would be difficult to do with the current code base, due to the way the kindlet invokes the parser - one shot, control doesn't go back and forth, data is passed back in a single stream
Thread history: I learned the hard way that KUAL development likes a simple incremental path.

Q for all: is a two-level nested menu, that is no sub-sub-... menus, just sub-menu, not enough for the vast majority of kindle use cases?

Ahhhh, I see. Is it really necessary to parse each time KUAL starts? Leave the output in temp, this way it only needs to actually parse once per reboot - or until that file gets deleted per request. The java does need more flexible handling if switching from shell script to java is undesired. If one sub-menu is easier to implement, then one should work. I can see a problem when one wishes to have sub-menus for system-tools, games, editors, ... - that uses up the one level, everything underneath would be flat.

[twobob]

I keep thinking of something intelligent to add.

"I got nothing."

perhaps more tea will bring new thoughts. nice work guys

[thomass]

Originally Posted by stepk

Q for all: is a two-level nested menu, that is no sub-sub-... menus, just sub-menu, not enough for the vast majority of kindle use cases?

agree

[stepk]

@thomass, you agree with a question? Is your answer politically correct or was my question?

[twobob]

not enough.

[thomass]

Originally Posted by stepk

@thomass, you agree with a question? Is your answer politically correct or was my question?

My mistake. I thought you were inclined to have a two level menu.

OK my answer: yes, I think two level is quite sufficient.

[n3rd4i]

what compiler do i need to make a build for kindle / Kindlet ?

[twobob]

ant is what I use.

[n3rd4i]

is someone interested in compiling dos2unix for Kindle 3 keyboard?

Edit: a better option is to compile DOSBOX for kindle, will help you use old DOS programs / Games, like XCOM, but i dont know how to do it...
I'm trying to compile something with ANT on windows but i get lots of errors...