Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Bad readability: Includes list in Project Explorer
Hi Morty,

My bias would be to put the configuration at the view level, rather than on individual projects. But that is just because that is where my mind went earlier (see my last email).

If you want to do that, the JDT code is here: PackagesView.LayoutActionGroup.

If you want to make it a per-project setting, then using a persistent property on the project may be the simplest thing to do. This is a property that is attached to a resource (e.g. an IProject), is persistent in the workspace, but not stored in the user's project. For this use case I think this is ideal as this setting is a view setting and not something that should generally be persisted in source control IMHO. See https://help.eclipse.org/latest/topic/org.eclipse.platform.doc.isv/guide/preferences_prop_implement.htm?cp=2_0_12_11_1 for more info, and the new extension wizard for a property page will make you a working little example:

image.png

I hope that helps and is in the right direction.

Jonah


~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Fri, 13 May 2022 at 10:47, Moritz Strübe <moritz.struebe@xxxxxxxxxx> wrote:
Hey Jonha,

ok I got 3 aggregation-strategies working. Now I'm struggling to make them configurable. I was thinking of having a drop-down entry for the includes folder. Unfortunately I'm overwhelmed by the abstraction layers. Maybe you (or someone else) can point me in the right direction. Also where to save the state and connect things. I don't think we need to persist things in the project*, but it probably doesn't hurt.

Morty

* IMO this should be project option, as the advantages of the different strategies depends on the layout of the include directories.

On 26.03.22 02:28, Jonah Graham wrote:

Hi Morty,

That would be a great improvement. I suppose once upon a time when includes were /usr/include having the full name all the time wasn't too much of an issue, but I agree the docker way is too long.

It would be merged (assuming it was well written/complete/etc). It is a CDT change - rather than point you at where to change, I have thrown together a first working version. You can use or discard it - its intention is to show you where to start looking:

It gives this instead of flat:
image.png

Doing something like JDT where there is a flat or hierarchical option may be a good idea:

image.png

But even better may be a semi-flattened semi-hierarchical where all the parents with just one child folder are collapsed to the same level in the tree (similar to your option 3 mock screenshot?).

I also really like your option 1 where in the UI you show the docker name of the folders rather than the .metadata name where they are copied. Hopefully you can play around to see what works best.

Here is the code - https://git.eclipse.org/r/c/cdt/org.eclipse.cdt/+/192262 - please feel free to use it as a starting point, or simply as a guide to what in the CDT code needs changing. 

Let me know how I can help support you getting this feature implemented.

PS This is a pretty fun bit of the code to work in - you get to see visible changes quickly and most of the code changes are internal packages of CDT so you don't have some of the other headaches of API compatibility. You'll notice that this is also some of the oldest parts of CDT, dating back to the early 2000s, so feel free to modernize code where you find it appropriate. For review sake it would help if modernized code was presented in separate commits.

Jonah




~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Fri, 25 Mar 2022 at 11:43, Moritz Strübe <moritz.struebe@xxxxxxxxxx> wrote:
Hey,

I finally have some time to work on docker improvements. One of the things bugging me are the include paths in the project. While they are already hard to read when they are no systems paths, but things get worse when they are copied from a docker image:



Thus: Is there an easy whey to fix this?
One of my ideas was to introduce some kind of mapping. Showing the actual path within the docker, but listing the copied files.
The second was to clip the paths on the left side instead of the right. But that is probably far from simple, because it breaks the rendering hierarchy, right?
A third option would be to introduce a hierarchy level. Adding one when all paths share the same base-path (or some other magic):



Thinking about it, the third option is probably the most non-confusing for the end-user, while still being implementable with reasonable effort (this is a wild guess, though).

Any thoughts? Would a patch be merged? Can this be implemented in CDT or do I have to adjust Eclipse? Pointers to the code to look at are welcome, too. :)

Morty


-- 
MATHEMA GmbH
Schillerstraße 14 | 90409 Nürnberg

Telefon: +49 (0)911 180778-50
E-Mail: moritz.struebe@xxxxxxxxxx | Web: www.mathema.de

Geschäftsführer: Andreas Hanke, Thomas Haug
Handelsregister: HR B 35517, Nürnberg/Bayern
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev


-- 
MATHEMA GmbH
Schillerstraße 14 | 90409 Nürnberg

Telefon: +49 (0)911 180778-50
E-Mail: moritz.struebe@xxxxxxxxxx | Web: www.mathema.de

Geschäftsführer: Andreas Hanke, Thomas Haug
Handelsregister: HR B 35517, Nürnberg/Bayern
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev

Back to the top