Am 08.05.2016 um 14:03 schrieb jeremy rosen: > Ok, multiple questions in here, i'll try to answer them as I can > > ABOUT LAYOUT OF BOXES > > what you are doing right now is not possible, the widget elements are new > in lua and everything is not exposed to lua yet. I add stuff on a need > basis and I didn't need fine-grained control on the layout so far. > > GTK (which is the real resplonsible for drawing the UI elements) has lots > of complicated options to control layout. I'm not sure exposing them to lua > would be simple/easy. I'll have a look at what's in there wrt layout and if > some controls can be easily passed to lua for users to play with
That would be great. I guess, several scripts that are already in the repository could benefit from more control over the GUI elements as well. Since Darktable uses its own set of GUI elements, that would not mean exposing all GTK features/elements, but just what DT uses. I mean, as a long term perspective :-) > RELOADING LUA SCRIPTS > > with the way lua works, it is not possible. you have to restart. This is > because lua doesn't load a script, it runs some code. there is no generic > way to revert what code did. your solution of setting package.loaded[] to > nil is dangerous. if it works for you, that's fine, but the risk of it > causing unexplainable behaviour exists. especially if you end up crating > the same thing (widget element, preference, shorctu...) multiple time I work on dummy data/database when working on code, therefore I feel somehow safe. However, a possibility to safely unregister/delete a lua-created module would be great. > LUA DOCUMENTATION > > As was pointed, your best source of documentation is the user manual (for > tutorial-like info) and the lua-api reference. (for complete reference) the > lua API, in particular is automatically checked against the source code and > is guaranteed to be up to date. no hidden feature*. If you are working with > master, I recommand generating it yourself and not getting it from the > website, so it contains all the latest stuff I know the existing documentation, however, my problem is somehow different. Not being a real programmer (electrical engineer by training) I have problems to see myself where the limits for Lua scripts are. Maybe, something not exposed in the DT Lua api may be possible to access/work around with pure Lua somehow. > LUA SHORTCUTS > > you can create shortcuts in lua, see > http://www.darktable.org/lua-api/ar01s03s03.html.php for details. This will > create a new shortcuts that will call some lua code. Note that you can't > use lua to assign shortcuts, only to create them. You need to assign a key > to your shortcut via the preference menu Any possibility to add functionality to dynamically show, register and unregister shortcuts including the keybinding from Lua? The entire set of shortcuts could be handed over similar to the image lists that are available. What I would need is the possibility to temporarily store the original shortcut config, temporarily remove most of them, temporarily set new shortcuts and restore the original config afterwards. Maybe this is possible to circumvent by trapping the key presses, but unfortunately I have no clue how that could work. > Overall i'd be interested in seeing your scripts,we do have a script repo > that accepts external contributions and any chance to have new > contributions is welcomed Thanks, I know the repo, I was already able to contribute a little fix to a script. For my actual ideas (and unfortunately I have a lot of them) I have very little code. I started with the speed tagging idea from the GUI side since it would not make sense without GUI. I wanted to check that it is possible first, because I am not able to add the missing items on the darktable side to make it run. Unfortunately, there is a lot missing to implement my idea, namely * fixes for better box alignment * dynamic access to shortcut configuration * more control over widgets, especially sizes, alignment and styles * backend to write configuration from lua (this is a nice-to-have, one could start writing an individual config file) Maybe I start with a simpler idea first. It would be great if I could ask about the limits of the current Lua API wrt my ideas from time to time here or, if that would be better, on IRC. Thanks for your detailed answer! Best regards Chris > *except the april 1st view, which can be accessed via lua > > On Tue, Apr 26, 2016 at 11:41 AM, Christian Mandel <c.man...@gmx.net> wrote: > >> Am 13.04.2016 um 10:20 schrieb Christian Kanzian: >> >>> Hi, >>> >>> Be aware I'm not a developer so my comments can be wrong. >>> >>> Am 09.04.2016 um 15:22 schrieb Christian Kanzian: >>>> >>>>> >>>>> [...] >>>>> >>>>> like the usermanual. What's written there is possible. If it is not >>>>> >>>> there you >>>> >>>>> simple can't do it. >>>>> >>>> >>>> That's one of the problems: Of course I try to learn from the >>>> documentation (especially the Lua API documentation), but it is not >>>> really very detailed and for me it is hard to understand where the >>>> limits are. E.g., some problems may be possible to circumvent or may be >>>> default Lua and therefore not documented in the API docs. >>>> >>> >>> Yes I'm in the same situation. Here is the default Lua: >>> https://www.lua.org/manual/5.2/ >>> Because I'm already middleaged, sitting all day long in front of a >>> screen I usually print this manuals for later reading ;-). >>> Takes a lot of time for me to get simple things working. E.g. until now >>> I still don't know howto reload a lua script without restarting darktable. >>> >> >> I experimented a bit because to restart dt all the time was annoying for >> me as well. Therefore, I found a partial solution. In my luarc file I >> register a new shortcut like this to reload my module: >> >> dt.register_event( >> "shortcut", >> function() >> package.loaded[ 'mymodule' ] = nil >> require "mymodule" >> print("module reloaded") >> end, >> "reload module" >> ) >> >> With this I am able to reload my module, but it does not overwrite the old >> one but adds a new instance. Therefore, I am able to reuse the session >> about 10 times before I have to restart dt. I did not find a way to really >> unregister a module (an inverse to dt's register_lib function), if someone >> has an idea here ... >> >> Should be easy from a developers point of view. What's even more >>> confusing is, that sometimes you need to know how darktable is supposed >>> to work. e.g. darktable.gui.action_images. >>> >>> >>>> Does your answer mean that everything I try to achieve is impossible at >>>> the moment? >>>> >>> No, that was more related to the UI elements and all the formating. >>> Maybe everthing is possible. >>> >>>> What extensions are planned, is it likely that these things >>>> become possible? >>>> I ask because I have a bunch of ideas of new >>>> features/modules for workflow speed-up that would perfectly suit the >>>> idea of Lua integration, all of them being little helpers of low >>>> complexity. >>>> >>>> [description of speedtagging module idea] >>>> >>>> Such a modul will be really helpful for me too, therefore I responded to >>> your mail. >>> >> >> Thanks for the moral support :-D >> >> >>> [Description of Christian K's scripts] >>> >>> Coming to your speed-tagging ideas: >>> 1.) shortcuts >>> ATM I can't imagine how shortcuts can be assigned via moduls. I'm not >>> aware of any place in darktable expect the references dialog where >>> shortcuts can be defined. Of course with lua you can add shortcuts to >>> the preferences dialog. So maybe there is by design no lua UI element >>> for shortcuts? There is a config file "keyboardrc" and with the in- and >>> output facilities of lua someone could mess around. But I think this >>> will bring you in hell's kitchen. >>> >> >> If there is no infrastructure now, maybe it can be established. Since the >> shortcuts can already be registered, maybe it is not that hard to directly >> assign them as well. But this generates a mess of storing old shortcuts, >> temporarily adding the new ones and then restore the old ones. Therefore, >> another, preferred, possibility would be to temporarily directly hook into >> the key input processing. While speed tagging is active, no other shortcuts >> should work, so it would be better to trap those events earlier. Maybe the >> rating and color shortcuts should be passed through. Unfortunately, I have >> no idea if this is possible. >> >> 2.) “use tags from last picture” >>> I usually tag several images at once. So what is the last picture if I >>> use "darktable.gui.action_images". >>> >> >> In the context of the speedtagging module it is clear, it is not the last >> picture but the last set of tags applied. The idea is that the pictures are >> sequentially shown full screen (the Alt-1 view). All the tag operations are >> done to the picture and then these tags are committed and the next picture >> is shown. If you have 20 pictures showing the same 7 people but the 4th >> picture has 2 of them missing, it would mean you have to press 8 key >> strokes for the first, 2 key strokes for the rest of them (use tags from >> last image and commit tags) and 2 additional ones for picture number 4 and >> 5 (the keys assigned for the 2 people missing). This would be much faster >> than marking all the pictures and adding the 7 tags in the conventional way >> and then removing 2 tags from picture 4, especially if you are using a deep >> hierarchy such as people|friends|John Doe and you know a lot of Johns. It >> becomes even more handy if there is more fluctuation of people on your >> images. This is a typical use case for me. 100 pictures with a subset of >> the same 10 people on each picture. This is really hard with the >> conventional tagging, especially since you are switching between mouse and >> keyboard really often to mark useful picture combinations and save time. >> >> 3.) shortcuts temporarily overwrite the general ones >>> A good question how shortcuts are handled now, because if you assign a >>> shortcut which is already in use this one will be removed from the old >>> position. >>> >>> Generally I would not start with UI elements, because you can add them >>> later on. Instead I would add shortcuts first, make the number of them >>> flexible, (use io of lua to save "presets" in a file) and if possible >>> push them to github* [2]. >>> >> >> I thought it would be nice to start from there since it is easier to >> explain the idea by the UI. If someone sees the panel with shortcuts on the >> left and tags on the right and a big activate button, I guess the >> functionality is immediately explained. And I therefore just first wanted >> to sort the gui and then proceed with the rest. But you are right in the >> sense that I have to learn all the other things as well. Any hints welcome >> :-) >> >> Thanks and best regards >> >> Chris >> >> >> ___________________________________________________________________________ >> darktable developer mailing list >> to unsubscribe send a mail to >> darktable-dev+unsubscr...@lists.darktable.org >> >> > > ___________________________________________________________________________ > darktable developer mailing list > to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org > > ___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
