KDevelop UI cleanup initiative

Jens Dagerbo jens.dagerbo at swipnet.se
Sun May 30 23:59:22 UTC 2004


> That is acutally not true. several standard indentifiers of several
> languages have man pages. As i remember from the top of my head: perl, tcl,
> python. For writing a bash script it might be the kicking feature.

Errr.. yes, of course. You're right. (Does it show that I don't leave C++ that 
often? ;) )

But configurable, please! :)


> I just remeber myself saying, that if we ever happen to get good context
> menus, one of the kdevelop-devs will become a XMLGUI guru. I think this
> still applies.

Or perhaps the other way around...

And if you find him, please have him take a look at the toolbars too, ok? ;)


> Just a note: I was always thinking, if i could make the diff tool view to
> "undock" it's content into a new window in the main area. I never got the
> time for doing it, though.
> But it is just plain imposible to view 2 diffs at the same time. Which is
> IMHO important, because i know no way (using the cvsservice plugin) to
> select more than one file and do a diff based on that selection.

I don't see how running a diff against two selected files is the same thing as 
seeing two diffs, but.. in the CvsService menu, "Difference Between Versions" 
let's you do this as long as one as you want to do diffs against the 
repository.

The diffpart could probably easily be extended to support doing a diff on two 
arbitrary local files (something that to me would be more useful than the 
current "inspect diff" feature). Without looking I think adding this is a 10 
minute job. 


> Hm, who was the guy that offered a new kdevelop logo few months ago? cies
> IIRC. Maybe we should ask him, if he can help.

Yes, and Ramón, who did our current splash image.


> > On this note, maybe we should make sure the various build managers use
> > the same icons to do the "same" thing? Currently, the QMake and Automake
> > managers have different icons for the same actions.
>
> Agreed. I do not start thinking about a unified project manager at this
> point. It would be a useless discussion :) But acutally, that would be the
> "sane" way to do it.

Yeah.. looong term. But not in the context of having more uniform icons.. ;)

> > > - we should rethink all our default short cuts. There are some that are
> > > so damn ugly... Depending on the type of keyboard you use,
> > > Alt+Ctrl+Shift+L needs two persons to press :)
> >
> > Well.. yeah. This particular shortcut I believe is defined by KMDI, but I
> > guess we could override it. We'd just have to do it in a way that
> > maintains any user override, if such exist. Nasty.
> >
> > In general, the way we just "get" shortcuts from embedded kparts is a
> > problem. A problem that needs solving, but probably not sanely so at the
> > KDevelop level. IMHO, one sane approach (at least to some degree) would
> > be for the kpart to not define shortcuts for its actions and leave this
> > up to the embedding app. At least a way to easily clear the default
> > shortcuts would be nice (maybe this already exists, I don't know all the
> > ins and outs of the XMLGUI architecture)
>
> hmm, this sounds like you want to add a big constraint to what a KPart may
> expose. Maybe this could break a lot of stuff; even outside kdevelop.

Not at all.. I don't want any contraints on exposed features or actions, I 
just don't want to be forced into using the part's set of shortcuts. As we 
see time and again, this creates problems.

Disregarding version issues, the solution might be as easy as this: 
Let the embedding app decide for the part what ui.rc file it should work with.

This would let the embedder (us) decide the layout of the part's menus and 
override its shortcuts.

Is this doable? Maybe already today? Is the version problem solvable?


> > > - File Create does IMHO no longer need an individual toolview; I
> > > recently changed the Toolbar action to have a popup menu. Though, it
> > > was always a good thing, but as ugly as can be.
> >
> > Agreed. Personally, I would be glad to see it go.
> >
> > It does already support optionally hiding that toolview, but (at least
> > last I looked at it) the code doesn't look completely finished and is
> > apparently unmaintained for some time now.
>
> Haven't seen that code yet. But also have never seen a ui for it 

Settings -> configure -> new file wizard -> use side tab (a checkbox, bottom 
right corner)

> - well, 
> this means nothing in file-create. Who acutally knows that there is a
> completely different ui implementation, which is just imposible to
> activate.... :-)

Yeah.. cool, isn't it? ;)


jd




More information about the KDevelop-devel mailing list