| Re: [papyrus-rt-dev] UML Real-Time preference pages |
Hi, all,I’ve raised bug 495325 for the top-level preference page and posted Gerrit 74441 with my proposed solution. Have at it. Perhaps discussion about this page, itself, can move into the bugzilla now.When this work is eventually merged, I can raise a new enhancement request for integration of the Xtext editor preferences into it. I have an idea how the Clear button for dialog settings can be consolidated into one (using the API provided by Xtext), but it needs some more thought.Cheers,Christian_______________________________________________On 2 June, 2016 at 12:05:14, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote:
Right. The top-level menu item invokes the code generator for textual UML-RT.We should probably get rid of that and unify the textual and graphical code-gen menus as well.I'm not sure yet how to go about it, as the textual plugins don't depend on Papyrus at all.
_______________________________________________On Thu, Jun 2, 2016 at 11:50 AM William Byrne <williamb@xxxxxxxxxx> wrote:Understood regarding the two menu items. And there's also this top menu which could be replaced by the generate button:Maybe we could use the Papyrus-RT icon for the button; though, it's not square:Here's an example pic of the Papyrus icon in action:CMake--------Now with support for Mac build & debug, I'm going to update the setup & usage guides (soon.) These guides will give us a good idea of what's required in the generated project. Maybe it's preferable to dispense with options and instead create the generated project with the required properties preconfigured.Verified build/debug thus far:WIndows: Visual Studio 2013 & 2015. Eclipse IDE via Cygwin, MSYSMac: YosetimeLinux: Ubuntu 12.04>>> "charles+zeligsoft.com" <charles@xxxxxxxxxxxxx> 6/2/2016 10:48 AM >>>_______________________________________________I’m not sure that this would be the best approach for those menu items. I think I would prefer an approach similar to the build tools, i.e., a button that would do the incremental code generation by default and a sub-button that would do a regenerate - an approach similar to make / make clean, but for codegen,
On 2016.06.02, at 10:36 , William Byrne <williamb@xxxxxxxxxx> wrote:
_______________________________________________Assuming CMake makes its way into the trunk, there are a couple of parameters that could be handled via the preferences page.And perhaps the model context menu could be reduced to a single item where regeneration (overwrite?) is handled as a preference.<Mail Attachment.jpeg>>>> Christian Damus <give.a.damus@xxxxxxxxx> 6/2/2016 9:33 AM >>>
Yes, that’s quite annoying, actually, because those preferences and their pages are all implemented in the Xtext run-time. I’m not sure how feasible it would be to unify that. It could be reason enough to leave the Xtext editor as a top-level preference node (ugh).cWOn 2 June, 2016 at 09:31:40, Peter Cigéhn (peter.cigehn@xxxxxxxxx) wrote:Hi,I guess it must be considered that the current "Umlrt" section already have the same kind of "Clear" button that is proposed:<Mail Attachment>So to avoid confusion, some alignment will definitively be needed./Peter Cigéhn_______________________________________________
On 2 June 2016 at 15:28, Ernesto Posse <eposse@xxxxxxxxxxxxx> wrote:
+1 to the preferences page
and+1 to unifying the name.For the preferences page, I think the Xtext preference page is contributed by Xtext itself, not our textual UML-RT feature. That feature does contribute the Umlrt page. More precisely it's the o.e.prt.xtumlrt.xtext.ui plugin that makes the contribution.I don't know if we should have the textual UML-RT preference page separate from the other or not. A unified page might be better, or we could have it separate. As Christian says, a bugzilla should be open.
On Thu, Jun 2, 2016 at 9:10 AM Peter Cigéhn <peter.cigehn@xxxxxxxxx> wrote:Hi,The only thing I can comment on is the name "UML Real-Time". I am not fully sure that we came to any conclusion in the Bugzilla that I wrote related to aligning terminology:I am not sure if really should be spelled with a - "UML Real-Time", or combined "UML RealTime", or with space "UML Real Time". I could so far see all kinds being used. I think that this would be a good opportunity to try to settle the terminology being used. Charles indicated (implicitly) though that it should be "UML Real Time" in the response he gave on that Bugzilla.Can we please settle this, and document the decision on that Bugzilla?/Peter Cigéhn_______________________________________________
On 2 June 2016 at 15:08, charles+zeligsoft.com <charles@xxxxxxxxxxxxx> wrote:
+1
On 2016.06.02, at 09:07 , SCHNEKENBURGER Remi 211865 <Remi.SCHNEKENBURGER@xxxxxx> wrote:
_______________________________________________Hi Christian,Great idea! Setting up right now the preferences contributions would be great, as for the discussion about labels convention.+1 for this proposalRegards,Rémi-------------------------------------------------------Rémi SCHNEKENBURGER+33 (0)1 69 08 48 48CEA Saclay Nano-INNOVInstitut CARNOT CEA LIST<image001.png>www.eclipse.org/papyrusDe : papyrus-rt-dev-bounces@xxxxxxxxxxx [mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx] De la part de Christian Damus
Envoyé : jeudi 2 juin 2016 15:02
À : papyrus-rt developer discussions <papyrus-rt-dev@xxxxxxxxxxx>
Objet : [papyrus-rt-dev] UML Real-Time preference pagesHi, Team,I observe that, so far, Papyrus-RT contributes no preference pages apart from those that are generated by Xtext for the xtUML-RT language (labeled as “Umlrt" [sic] in the preference dialog).I have a need for addition of a new preference page, so I would like to discuss the presentation. In the refactoring of a simple state into a composite state, I want to prompt the user for confirmation on double-clicking a state, with the usual “don’t ask again” check box. To that end, a preference will be needed to restore the prompting.I propose a new preference page hierarchy as follows:
- UML Real-Time <— top-level page for all Papyrus-RT preference pages
Pretty simple, hunh? 😉For now, the top “UML Real-Time” preference page would have only the dialog settings button as in JDT:<image002.png>except, of course, titled “UML Real-Time dialogs”. There would be a new API in which each dialog’s preference key is registered to be managed by this Clear button.Comments? Votes?Thanks,Christian
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev