Community
Participate
Working Groups
I've recently kept track of the development of this project in github: https://github.com/jeeeyul/eclipse-themes What initially started as an alternative simple theme has grown in a solid theme customizer with plenty of features. Actually it is present as an offering on the marketplace here http://marketplace.eclipse.org/content/eclipse-4-chrome-theme Should we consider making this part project of Eclipse? Maybe initially on e4 incubator and when it's mature enough make it part of the default selection of themes among the default ones? Also this would expose the project to further contribution.
That sounds like a great idea... Also it might be nice to provide a spot on the marketplace to pick up new themes...
@Sopot: Would Jeeeyul interested in contributing this theme to Eclipse?
I have contacted him to state his opinions on this bug. CC'ing some people which (I think) should give opinions.
I love to contribute. but I have some worries about my hack codes which seems to not honor other contributors and API contracts.
In which parts are those hacks needed ? If the framework leaves you no choice but to hack around in order to build a customized theme than I guess we are open for enhancements on the framework itself. It would be great if you file some bugs on platform/ui detailing the missing public API or blocks you faced while building your theme and customizer. This way we can gradually turn your code into "well behaved" code.
Major problem is strong cohesiveness of CTabFolder, CTabItem and CTabFolder renderer. CTabFolderRenderer works with CTabFolder using package visibility APIs. And CTabFolderRenderer doesn't have an Interface to co-operate. So custom renderer must have to extend CTabFolder renderer, but can't use API of parent. (since they have Package Visibility) Custom renderer can compute each part(of CTabFolder) size, but can't determine every details. for instance, Custom renderer doesn't have an way to know bounds to draw close button for each CTabItem. because of, CTabItem stores bounds as a package visibility field, and it is computed by CTabFolder. with this restrictions, CTabFolderRendering in e4 already have some hacks already. I did let my renderer extends CTabFolderRendering, so Hacks became more worse. So CTabFolder, CTabItem should have to be rewritten to get more flex co-operation with CTabFolder renderer. Other problems are relatively minor. - SashLayout(e4) doesn't have APIs to set margin and sash width. - There is no way to set padding of Top Window.
Where can I open a bug for enhancement of CTabFolder
https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Platform&component=SWT&bug_severity=enhancement
AFAIK Tom and Kai are working on a new renderer implementation. If you open a new bug, please copy them into the bug.
(In reply to comment #9) > AFAIK Tom and Kai are working on a new renderer implementation. If you open > a new bug, please copy them into the bug. CTabFolder has nothing to do with renderer implementations because it is completely controlled by CSS and SWT.
css/swt, renderer have no chances to fix these cohesiveness problems. This problem lies on CTabFolder and CTabItem, CTabFolderRenderer. As I reverse engineered current CTabFolderRendering(CTabFolderRenderer which supports CSS), It uses CTabFolder's rendering methods indirectly through it's parent class(CTabFolderRenderer). CTabFolderRenderer delegates pretty many things to CTabFolder using package visible interface. as A Result, current implementation of CTabFolderRendering is very cohesive with CTabFolder. I will inspect problems more deeply, and I will open bugs against of CTabFolder.
Thanks Jeeeyul, this is great input !
I'm not sure this bug belongs to e4, moving to Platform. Feel free to move it back. Things I like to see from Jeeeyul in the standard: - Ability to set the Sash Width - Ability to turn on / off MRU
I suggest we open more specific bugs to enhance our default theme with ideas from the chrome theme. I mark this one as WONTFIX, this does not mean that I think that we should migrate ideas from the Chrome theme to our default theme, I just think we should be more specific with the bug reports.
Lars, I'm unclear as to why you marked this as WONTFIX. If Jeeeyul is OK with submitting it I think that it would be a good thing overall. Note that this is unlikely to happen in Luna simply because we haven't vetted the UI for various 'enterprise' aspects like accessibility and NLS support (Jeeeyul, do you know what the state of this is ?). Just to clarify, the new CTabFolder implementation uses an *internal* renderer that has not been exposed as API but is needed to tweak the CTF UI in various low level ways. Lars, I certainly agree that if we package this with the IDE then it (or a derived flavor) should be the default way for users to tweak the CSS and the text-based CSS editor should be secondary (or merged somehow).
(In reply to Eric Moffatt from comment #15) > Lars, I'm unclear as to why you marked this as WONTFIX. If Jeeeyul is OK > with submitting it I think that it would be a good thing overall. N I have a bug open on Jeeeyuls side and he did not answer that. So far it is unanswered and I think that means Jeeeyuls prefers not to contribute it. For reference https://github.com/jeeeyul/eclipse-themes/issues/99 Also email reminders remained unanswered. If he changes his mind, can should reopen this bug.
He seems busy developing new features. (The kickass gradient editor is seriously a couple of months new and the latest update added hue shifting to it, also fixed bug 430872 just because I guess.) Maybe you could fix whatever is blocking its inclusion in Eclipse and send him a pull request? Worked for me and my issue...
Still seems like a shame to me...;-(, it'd be a great step forward IMO...
