[FR] UI Feature Request and others ideas 01 (in-process-out) and metadata manager.

[difrkaguilar]

From #8453

export module with the progress bar, must be always at the same position in the lighttable and in the darkroom, not at the left in the lighttable, and at the right in the darkroom. With this idea, the export module must be on the right panel, at the bottom

I agree with your point about consistency, but the organisation of the darkroom is to have all the (many) processing modules on the right side, so having one exception for export would imho be confusing and take up valuable space. I'd rather move it to the left in lighttable.

The logic in lighttable then would be to have import/export and collections on the left and item selection and manipulation on the right. Image information on the left is "just because more space" and tagging would still be inconsistent between lighttable and darkroom, but it doesn't feel like it would lead to confusion to me.

Originally posted by @dterrahe in https://github.com/darktable-org/darktable/issues/8453#issuecomment-799575564

---

I was trying to understand the interface and propose a consistency between the lighttable and the darkroom into an in / processing / out.

In this proposal in the lighttable I moved all relative to tagging images to the left with the import, and manage collections modules. The image organization and scripts to the right.

The same way in the darkroom, the tagging will remains to the left.

Looking for consistency in the interface the idea is to have only one metadata editor. Not two, one for the import process and other for the images after import inside the lighttable.

This metadata editor module will work as "if" directly linked with the import module. For instance: when users import a folder, if they check "apply metadata on import" then this option override the apply button in the metadata editor (apply button off), but users will select their own presets, and info. So in this case the metadata is goin to be apply to all newly imported images.

If "apply metadata on import" is off, then the metadata editor can be used in the selected images inside the lighttable as usual. So the apply button will be active, presets and all the relative info can be used as well.

[elstoc]

Not a fan of putting lib modules on the right-hand-side of the darkroom. It's a trade-off between having consistent locations and efficiently managing the available space. I prefer the latter.

[dterrahe]

I appreciate all the thought and effort you are putting into rethinking things, but I'm afraid that unfortunately none of the ideas proposed here appeal to me.

1. The darkroom is meant for developing images. There are many modules computing for space on the right side. Some, especially when masking is on, already on their own take (almost) the full height so we have spent a lot of effort to make them as space efficient as possible. Dumping the export module in there (which can be quite large itself) is not a good idea. When I recently suggested adding the export module to the darkroom the thought was that (when collapsed) it doesn't take too much space on the left, I certainly wasn't imagining it encroaching on the core purpose of the darkroom in a significant way.
2. metadata for importing should be fairly constant (name, copy right). You wouldn't want to accidentally mess that up because you were editing/correcting one specific image that had wrong or different requirements and then forget (since it is in separate module) to put it back for your next import and have it all messed up. Yes, I understand there's duplication in the look (but presumable the parameters section of the import module is collapsed most of the time) but they are really there for different purposes. Defaults for import != editing.

[AlicVB]

Maybe I'm just a too old dt user to change my mind, but -even if I can see the usecases- I'm not a fan of all that modules added in darkroom : in my mind we already miss space here to do editing, so we need to be very conservative in what is added. Not to speak that I expect the list of editing modules (iop and libs) to grow up in the future...

I personally prefer the disadvantage of having to go back to lighttable to do things...

Note that in that aspect, there's also other way to explore, like what does ctrl-t actually, or like an "extended" ctrl-e feature (I'm working on it actually)

That said, as @dterrahe , I really like the effort you've put on all your proposals !

[wpferguson]

@paperdigits commented on #8497 with

However, this would be a lot of work for one or even many developers to undertake. It would probably take several years, as this is a complete rewrite of the GUI. Generally we like our changes, especially UI, to be quite small, so that someone can tackle it and get the improvement merged rather quickly.

which started me thinking how to implement a UI rewrite or change. There are countless "let's fix the darktable UI" threads with pictures and ideas. The problem is that to test any of them will take a huge investment in development that, in the end, may lead to a user interface that looks pretty and is pretty useless.

So, to borrow an idea from web design, can we separate the view from the controller(s)? Maybe an IOP generates a bunch of widgets, then sends it to a template (darktable template language? dttl anyone?) to get displayed. Possibly there are partials (I'm stealing from Rails here) to just do certain parts. Smaller templates are called from larger templates. Templates are themeable.

If the view worked in this way then testing a new UI idea is simply(?) creating a new template with possibly a new theme. New templates can be put out for usability testing to see if the idea actually works or not.

[difrkaguilar]

It's another idea, but as you commented it will take a lot of time and investment to developers, and many of this changes and others that I proposed in #8453 post are focused in the interface.

But my personal opinion is that make a themeable app with as many templates as users can create will split and fracture darktable own identity and will become in an extra exffort for developers to merge all in an effective app.

In this case I prefer first the functionality and after the aesthetics.

[wpferguson]

My idea was about how to reduce the cost of changing the interface. Any changes, including yours, require recoding the interface. If we can come up with a way to reduce the cost from years to months or weeks, then we can actually test an interface change and see if it really works or not. And, if we make a mistake we can respond and fix it in a more timely manner. Of course, that's only if my idea is possible or workable.

[quovadit]

Does it make sense to start a kickstarter campaign to pay a full-time developer for 1 month (?) to get the redesign job done quickly? Krita had several successful campaigns there ...

[dterrahe]

My idea was about how to reduce the cost of changing the interface.

We are currently not even fully using gtk to enable more themeability. But generalising the interface takes a lot of concentrated dedication and work, because all our existing code base will need to change to conform to some new vision. Gtk (or gtk4, which we haven't even decided if we'll ever find the time to port to because it's such a huge job) might not be flexible enough to really support what you are suggesting. So it would mean an even more fundamental framework change. Or write our own, which is what gnome did and which resulted in gtk, a fully spun off project.

[dterrahe]

Does it make sense to start a kickstarter campaign to pay a full-time developer for 1 month (?) to get the redesign job done quickly?

I am sure this is not meant to be insulting, but you may underestimate the amount of work that is already going into the current UI (leading to a state you find totally unsatisfying).

Who are you going to give that money to? One of the current developers, who know the codebase and would hit the ground running, thereby demotivating the other volunteers so that net-net you lose developer time? Or some fly-by-night outsider, who would just spend that month trying to figure out how everything works and insulting everybody about the sad state of affairs, or simply dump some glitter on top and run, while others (if they are still around) are left to clean up the mess?

It is nice if people contribute to the discussion and provide artwork and suggestions, but the starting point has to be the understanding that if there was a simple solution to all the issues users see, the developers (who are also users) would have implemented it. Yes, there might be multi-year plans that require a strategy and buy-in to realise and we should discuss that more to see if we can reduce fragmenting developer effort. Which would mean less time spent polishing the current situation (and weather user complaints about that) and possibly seeing some developers lose interest.

[quovadit]

wow, I'm really sorry if I offended anybody, I am far away of underestimating the great work already done by the current developers, and I never said that I find the current state totally unsatisfying.

I just saw that other open-source projects did crowdfunding, and I asked whether it makes sense to do the same for dt.

I understand all the risks you mentioned, but I thought a redesign would be a job that can be done by an outsider, especially if he follows the suggestion of wpferguson to separate the view from the controller(s).

[dterrahe]

Don't worry, my phrasing was awkward, but I really meant that I didn't think you meant to insult :-)

I thought a redesign would be a job that can be done by an outsider, especially if he follows the suggestion of wpferguson to separate the view from the controller(s).

But that's the thing, "separat[ing] the view from the controller(s)" is work that would need to be done first and that's a huge undertaking, reaching deep everywhere in the existing codebase, needing to clean up or work around all the existing work-arounds so that they don't clash. Even designing the plan for that would take months and need the input from other developers. Just try to bring up a discussion like that; nobody has time. If an outsider did all of this, they'd still end up breaking lots of stuff so testing and fixing would need all hands on deck.

Now if you found enough money to sponsor a team for a year...

[wpferguson]

So it would mean an even more fundamental framework change.

Hence the

Of course, that's only if my idea is possible or workable.

I should have added on the end "and it probably isn't". The idea is tumbling around in my mind and one day I may come up with some wonderful idea about how to accomplish it, but I'm not holding my breath in the meantime. And, I have enough stuff to keep me busy, so I wasn't looking to take on something else :-).

[dterrahe]

I love the idea! If you promise not to tell anyone, I'm actually more interested in frameworks than applications. Well, maybe you can tell from #8078.

But I believe that any change like that, no matter how well thought out, will after the initial brilliant ideas require a lot of hard work. Not because the new framework might be complex (it could maybe be very elegant and simple to implement a new themeable application with it) but because the dt codebase contains so many gtk specific hacks and workarounds.

That's why people like hanatos actually do, and people like aurelien dream about, starting from scratch. But dt contains so much embedded knowledge that rebuilding that would be a huge task too.

BTW @wpferguson I'm not telling you this, of course; you know. But to people contributing in different ways and with maybe less coding experience (or specifically experience with the dt codebase) it may just not be as obvious. To them our dreams may sound like things we could start working on tomorrow and finish next month.

[difrkaguilar]

Really sorry if my post created a controversial debate about redesign the darktable UI, this wasn't my intention. As you can see in all my screenshots, I follow in all cases the actual guidelines and design rules darktable have to maintain it's identity, I don't propose another UI, just a re-arrange of some modules and icons, like stars rating and colors inside darkroom or the two side icons to expand or collapse panels (not the arrows in the middle position of the panels).

I 'm not reinventing the boiled water, just taking the bootstrap set of icons widely used in a lot of applications and webs, tried to make tiny changes, not a drastic change to the UI.

Perhaps all this was my fault because I proposed many changes in a single post, and days later I wrote this one and the main post with those changes #8453 has fallen in the forgotten (except @s7habo @dterrahe and @jandren answers there aren't other interactions), despite the export module that was debated about the real utility of been at the right bottom corner. Other changes can be analyzed. I encourage the developers to analyze in depth those features request to the UI posted in #8453 more than this post we are actually in debate.

Actually the mask manager module really needs a redesign to be more useful with visuals indicators of transparency per mask, or lock a mask to work with others among other things.

Other things can be made are handlers in ellipse or circle mask, almost every computer user in 20 years know when an object is selected (mask in this particular case) there are some actions that can be made, and handlers are a guide to do it. Not all users have the ability to remember shortcuts for every action to make, there are users of different ages working with the app. In the case of circle/ellipse mask there are some tricky combinations.

scroll mouse button = increase / decrease size ctrl+scroll = increase / decrease transparency ctrl+schift+scroll = rotate (by step of 10 degree)

It's a real pity that I'm just a designer and my programing skills are near to cero and I can't help more deeply in the codding and programing process.

[wpferguson]

I 'm not reinventing the boiled water, just taking the bootstrap set of icons widely used in a lot of applications and webs, tried to make tiny changes, not a drastic change to the UI.

So how many dev-hours do you think this should take?

It's a real pity that I'm just a designer and my programing skills are near to cero and I can't help more deeply in the codding and programing process.

A couple of years ago Aurélien Pierre couldn't write a line of C code. He learned C, learned darktable, and is now a major contributor.

[difrkaguilar]

So how many dev-hours do you think this should take?

I know is a lot of work too, but not compared with redesign the UI. I have a lot respect to developers, and know that many of you make possible all those great improvements in apps like darktable. By the way a lot of thanks for every script you have created, are great to increase the darktable functionality.

A couple of years ago Aurélien Pierre couldn't write a line of C code. He learned C, learned darktable, and is now a major contributor.

That's him that is a genius :-)

[wpferguson]

That's him that is a genius :-)

I think you could be right :smile:

[github-actions[bot]]

This issue did not get any activity in the past 30 days and will be closed in 365 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[github-actions[bot]]

This issue did not get any activity in the past 60 days and will be closed in 365 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[Nilvus]

@difrkaguilar: thanks again for your mockup. This helps me improving UI with some icons ideas. Such a UI update would be huge but this help me finding new icons for darktable UI. If you have ideas for thumbnails in lighttable, I'm all on. Just think about mockups that could easily deal with actual thumbnails (mainly keeping actual square around images). For more, this will also need someone able to rework Gtk code (so not me).