Re: 4.12.1
On 4/10/14 10:43 PM, Justin Mclean jus...@classsoftware.com wrote: I think we should re-add the try/catch blocks as requested in FLEX-34218 I rather not if we can avoid it as a) it has worse performance b) silently catches and throws away user errors. OK, maybe you should respond to FLEX-34218 and see what the customer has to say. -Alex
RE: 4.12.1
I know Maurice sort of volunteered to the the RM, but maybe someone else should just cut an RC for 4.12.1. Yes, I volunteered, but in the meantime, I got committed to a critical delivery to be scheduled early May (that's why I am not very active on a.o at the moment). So if the work on 4.12.1 can wait until after that, I will be happy to keep my promise, If it can't wait, someone else can do it as you suggest. Maurice -Message d'origine- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : vendredi 11 avril 2014 00:23 À : dev@flex.apache.org Objet : 4.12.1 I'm hopeful we'll approve a FlexJS soon and folks wanting to use an installer for FlexJS need to use InstallApacheFlex 3.0 which has enough votes to release, but because it will cause a locale issue with 4.12.0, we've agreed to delay officially releasing the Installer until 4.12.1 is released. I would definitely like to get FlexJS out soon so we can generate some buzz and hopefully get a few more folks to join us at 360|Flex. So: 1) Should we close the vote on Installer 3.0 and post it to the release server and just not announce it or make the switch that auto-upgrades the Installer? One potential problem is that if folks then use that installer to install a regular SDK they may hit this locale issue, although several folks have used the installer in other locales and did not hit this issue. 2) what else do we want to fix in 4.12.1? I know Maurice sort of volunteered to the the RM, but maybe someone else should just cut an RC for 4.12.1. I'm thinking we should put the try/catch blocks back in DataGrid/ADG itemToLabel as described in [1]. I think there is one more I saw but I can't find it right now. Any others? -Alex [1] https://issues.apache.org/jira/browse/FLEX-34218
Re: flex-sdk_mustella-mobile - Build # 650 - Still Failing!
This test: mobile/ViewAndViewNavigator/tests/ViewAndViewNavigator_persistence customObjectPersistence Failed AssertMethodValue (method cannot be shown)(body:step 2) method returned false, expected true is now consistently failing every time the 'mobile' suite is run. This seems to indicate a regression somewhere... EdB On Fri, Apr 11, 2014 at 10:48 AM, flex.muste...@gmail.com wrote: flex-sdk_mustella-mobile - Build # 650 - Still Failing: http://flex-mustella.cloudapp.net/job/flex-sdk_mustella-mobile/650/ Changes for Build #647 Changes for Build #648 Changes for Build #649 Changes for Build #650 [aharui] FLEX-34200 accept patch [...truncated 12884 lines...] [java] apollo adj thinks it's a swf [java] writing Apollo file! [java] full swf is C:\jenkins_slave\workspace\flex-sdk_mustella-mobile\mustella\tests\mobile\SkinnablePopUpContainer\swfs\SkinnablePopUpContainerApp.swf [java] post ApolloAdjuster: C:\jenkins_slave\workspace\flex-sdk_mustella-mobile\mustella\tests\mobile\SkinnablePopUpContainer\swfs\SkinnablePopUpContainerApp.xml [java] new test file: C:\jenkins_slave\workspace\flex-sdk_mustella-mobile\mustella\tests\mobile\SkinnablePopUpContainer\swfs\SkinnablePopUpContainerApp.xml [java] cmdArr before: [java] C:\ApacheFlex\dependencies\AdobeAIRSDK\3.7\bin\adl.exe [java] C:\jenkins_slave\workspace\flex-sdk_mustella-mobile\mustella\tests\mobile\SkinnablePopUpContainer\swfs\SkinnablePopUpContainerApp.xml [java] moreParameters before: [java] -screensize [java] 640x960:640x960 [java] -profile [java] mobileDevice [java] -XscreenDPI [java] 240 [java] cmdArr after: [java] C:\ApacheFlex\dependencies\AdobeAIRSDK\3.7\bin\adl.exe [java] C:\jenkins_slave\workspace\flex-sdk_mustella-mobile\mustella\tests\mobile\SkinnablePopUpContainer\swfs\SkinnablePopUpContainerApp.xml [java] -screensize [java] 640x960:640x960 [java] -profile [java] mobileDevice [java] -XscreenDPI [java] 240 [java] getting directory from the swf file [java] derived directory: C:\jenkins_slave\workspace\flex-sdk_mustella-mobile\mustella\tests\mobile\SkinnablePopUpContainer\swfs [java] Launching: [java] C:\ApacheFlex\dependencies\AdobeAIRSDK\3.7\bin\adl.exe C:\jenkins_slave\workspace\flex-sdk_mustella-mobile\mustella\tests\mobile\SkinnablePopUpContainer\swfs\SkinnablePopUpContainerApp.xml -screensize 640x960:640x960 -profile mobileDevice -XscreenDPI 240 Launching: C:\ApacheFlex\dependencies\AdobeAIRSDK\3.7\bin\adl.exe C:\jenkins_slave\workspace\flex-sdk_mustella-mobile\mustella\tests\mobile\SkinnablePopUpContainer\swfs\SkinnablePopUpContainerApp.xml [java] USING directory: C:\jenkins_slave\workspace\flex-sdk_mustella-mobile\mustella\tests\mobile\SkinnablePopUpContainer\swfs [java] time: 03:47:43.643 [java] SCRIPTDONE! 03:47:49.859 [java] GET /ScriptComplete?0 HTTP/1.1 [java] Before Wait loop 03:47:49.859 waiting = 0 [java] After Wait loop 03:47:49.859 waiting = 0 [java] clobberProcess false [java] Total Results so far: 1 [java] removing the xml app file [java] Grab log, do parse = false [java] Grabbing the log from: C:\Users\ApacheFlex\AppData/Roaming\Macromedia/Flash Player/Logs/flashlog.txt to: C:\jenkins_slave\workspace\flex-sdk_mustella-mobile\mustella\tests\mobile\SkinnablePopUpContainer\swfs\SkinnablePopUpContainerApp.log [java] apollo adj with : C:\jenkins_slave\workspace\flex-sdk_mustella-mobile\mustella\tests\mobile\ViewAndViewNavigator\swfs\ViewAndViewNavigatorMain.swf [java] apollo adj thinks it's a swf [java] writing Apollo file! [java] full swf is C:\jenkins_slave\workspace\flex-sdk_mustella-mobile\mustella\tests\mobile\ViewAndViewNavigator\swfs\ViewAndViewNavigatorMain.swf [java] post ApolloAdjuster: C:\jenkins_slave\workspace\flex-sdk_mustella-mobile\mustella\tests\mobile\ViewAndViewNavigator\swfs\ViewAndViewNavigatorMain.xml [java] new test file: C:\jenkins_slave\workspace\flex-sdk_mustella-mobile\mustella\tests\mobile\ViewAndViewNavigator\swfs\ViewAndViewNavigatorMain.xml [java] cmdArr before: [java] C:\ApacheFlex\dependencies\AdobeAIRSDK\3.7\bin\adl.exe [java] C:\jenkins_slave\workspace\flex-sdk_mustella-mobile\mustella\tests\mobile\ViewAndViewNavigator\swfs\ViewAndViewNavigatorMain.xml [java] moreParameters before: [java] -screensize [java] 640x960:640x960 [java] -profile [java] mobileDevice [java] -XscreenDPI [java] 240 [java] cmdArr after: [java] C:\ApacheFlex\dependencies\AdobeAIRSDK\3.7\bin\adl.exe [java]
Re: Docs on TLF composition?
I think the doc is coming together. I'd love to get some feedback on how I'm doing… Is it clear enough to understand? Suggestions on how to improve it? Other areas I should be covering? Harbs On Apr 7, 2014, at 1:25 PM, Harbs wrote: I started documenting it here: https://docs.google.com/document/d/1u-ljSsTjZORoUVQtJT9gt0wcZxBBkRZaGza3MbzNsL8 I'll be adding to the doc as I go. I enabled commenting for anyone with a link. Please add comments to correct anything I have wrong. If anyone wants editing rights, let me know… Harbs On Apr 6, 2014, at 8:26 PM, Alex Harui wrote: I don't know of any. It would be great if you could document it. On 4/6/14 5:27 AM, Harbs harbs.li...@gmail.com wrote: I'm referring more to the composition lifecycle. (i.e. Text is marked damaged by x, Class y is called to start compostion by y. Composition is started by z, the process continues with lmnop, etc. How does ContainerController, BaseCompose FlowComposer, etc. all interact with each other.) It's really hard to work on a framework, when the details on its architecture is really sketchyŠ On Apr 6, 2014, at 2:01 PM, Maurice Amsellem wrote: This one maybe ? http://help.adobe.com/en_US/as3/dev/WSb2ba3b1aad8a27b0-1b8898a412218ad3df 9-8000.html -Message d'origine- De : Harbs [mailto:harbs.li...@gmail.com] Envoyé : dimanche 6 avril 2014 12:55 À : dev Objet : Docs on TLF composition? While working on TLF, I constantly forget the finer points of the composition flow. It's highly inefficient to constantly step through the code to figure out exactly what happens when and by what. I'm thinking of putting together a doc which specifies the flow and how all the classes work together. Before I do this, I'm wondering if anyone knows of any documentation explaining the architecture. Harbs
Karma for wiki
Could someone give me editing writes on the wiki? (user id: Harbs) Thanks, Harbs
Re: Karma for wiki
OK, give it a try. On 4/11/14 6:17 AM, Harbs harbs.li...@gmail.com wrote: Could someone give me editing writes on the wiki? (user id: Harbs) Thanks, Harbs
Re: Karma for wiki
I'm in. Thanks. On Apr 11, 2014, at 5:28 PM, Alex Harui wrote: OK, give it a try. On 4/11/14 6:17 AM, Harbs harbs.li...@gmail.com wrote: Could someone give me editing writes on the wiki? (user id: Harbs) Thanks, Harbs
How to deal with Falcon/CompC FDKs?
Hi, I finally managed to have the Mavenizer use Falcon to compiille the Theme SWCs and it seems to be running fine :) Now I had the problem, that currently it would be possible to have two variants of mavenized compiler in the FDK. So how should web e able to distinguish between both? If I for example generate a org.apache.flex:compiler:pom and a org.apacche.flex:compiler-falcon, I guess this would be a problem, as including compiler-falcon in the maven config wouldn't override the compiler version that is included per default. So If Flexmojos was built against 4.12 and I wanted to use Falcon in version 4.13, the maven build would user compiler-4.12 and compiler-falcon-4.13, which could be really bad. Another option would be to add classifiers: so the falcon and the compc version would both be called compiler, but one would have the cclassifier compc and one would be falcon. Then the Override mechanism would work. I would then make Flexmojos use compc as defaullt and we should have a minimal impact on that. Unfortunately classifiers can't be used for this as if you have mmultiple artifacts with different classifiers, they still share the same pom and classifiers seem to be not availablle for pom-modules. One way to solve this problemm would be to instead of creating a cpmpiler pom artifact, to create a jar artifact, that contains all the jars content of all the dependencies of the pom, but I think this is pretty ugly :( So I would have another proposal: How would it be to keep the compiler the way it was allways done including compc and mxml and to add another pom that contains falcon and to change Flexmojos to check for falcon and as soon as that's availallbe it would use that, if not it would use the default. Now we would have MXML, CompC and Falcon in the build path but from a maven perspective this would be the cleanest solution. What do you think? Chris
Re: How to deal with Falcon/CompC FDKs?
Hi Chris, Not sure I fully understood this, but consider thinking about MXMLC and Falcon as different sub compilers supplied by different companies. I would imagine there are other sub compilers in the Maven universe, no? For a while, at least, folks building projects may wish to use Falcon or revert back to MXMLC if there are bugs in Falcon, so having the compiler be a separate dependency should allow them to choose their compiler by changing a dependency somewhere. And better yet, Falcon and MXMLC are Java projects and may not need a mojo. I am open to creating a separate MXMLC-only release package if that helps. Does that help toward a solution? -Thanks, -Alex On 4/11/14 9:18 AM, Christofer Dutz christofer.d...@c-ware.de wrote: Hi, I finally managed to have the Mavenizer use Falcon to compiille the Theme SWCs and it seems to be running fine :) Now I had the problem, that currently it would be possible to have two variants of mavenized compiler in the FDK. So how should web e able to distinguish between both? If I for example generate a org.apache.flex:compiler:pom and a org.apacche.flex:compiler-falcon, I guess this would be a problem, as including compiler-falcon in the maven config wouldn't override the compiler version that is included per default. So If Flexmojos was built against 4.12 and I wanted to use Falcon in version 4.13, the maven build would user compiler-4.12 and compiler-falcon-4.13, which could be really bad. Another option would be to add classifiers: so the falcon and the compc version would both be called compiler, but one would have the cclassifier compc and one would be falcon. Then the Override mechanism would work. I would then make Flexmojos use compc as defaullt and we should have a minimal impact on that. Unfortunately classifiers can't be used for this as if you have mmultiple artifacts with different classifiers, they still share the same pom and classifiers seem to be not availablle for pom-modules. One way to solve this problemm would be to instead of creating a cpmpiler pom artifact, to create a jar artifact, that contains all the jars content of all the dependencies of the pom, but I think this is pretty ugly :( So I would have another proposal: How would it be to keep the compiler the way it was allways done including compc and mxml and to add another pom that contains falcon and to change Flexmojos to check for falcon and as soon as that's availallbe it would use that, if not it would use the default. Now we would have MXML, CompC and Falcon in the build path but from a maven perspective this would be the cleanest solution. What do you think? Chris
AW: How to deal with Falcon/CompC FDKs?
Ok ... well another option would be to strip the default compiler from flexmojos. The upside would be that I could give both compiler artifacts different names and the user could decide which one he wanted to use by adding the corresponding dependency. The downside would be that it would no longer be possible to beginnners to start with Flex and Flexmojos without providing a compiler. But thinking about that ... I never liked the default anyway. So how about the Mavenizer creatng: For the current MXML compiler: dependency groupIdcom.adobe.flex.compiler/groupId artifactIdmxml-compiler/artifactId versionfdk-version/version typepom/type /dependency For Falcon: dependency groupIdcom.adobe.flex.compiler/groupId artifactIdfalcon-compiler/artifactId versionfdk-version/version typepom/type /dependency And to get rid of the current: dependency groupIdcom.adobe.flex /groupId artifactIdcompiler/artifactId versionfdk-version/version typepom/type /dependency Any objections? Cool thing ist hat I should be able to change FM7 to support these changes without breaking the builds of people having FDKs mavenized by previous versions of the Mavenizer. Chris -Ursprüngliche Nachricht- Von: Alex Harui [mailto:aha...@adobe.com] Gesendet: Freitag, 11. April 2014 18:27 An: dev@flex.apache.org Betreff: Re: How to deal with Falcon/CompC FDKs? Hi Chris, Not sure I fully understood this, but consider thinking about MXMLC and Falcon as different sub compilers supplied by different companies. I would imagine there are other sub compilers in the Maven universe, no? For a while, at least, folks building projects may wish to use Falcon or revert back to MXMLC if there are bugs in Falcon, so having the compiler be a separate dependency should allow them to choose their compiler by changing a dependency somewhere. And better yet, Falcon and MXMLC are Java projects and may not need a mojo. I am open to creating a separate MXMLC-only release package if that helps. Does that help toward a solution? -Thanks, -Alex On 4/11/14 9:18 AM, Christofer Dutz christofer.d...@c-ware.de wrote: Hi, I finally managed to have the Mavenizer use Falcon to compiille the Theme SWCs and it seems to be running fine :) Now I had the problem, that currently it would be possible to have two variants of mavenized compiler in the FDK. So how should web e able to distinguish between both? If I for example generate a org.apache.flex:compiler:pom and a org.apacche.flex:compiler-falcon, I guess this would be a problem, as including compiler-falcon in the maven config wouldn't override the compiler version that is included per default. So If Flexmojos was built against 4.12 and I wanted to use Falcon in version 4.13, the maven build would user compiler-4.12 and compiler-falcon-4.13, which could be really bad. Another option would be to add classifiers: so the falcon and the compc version would both be called compiler, but one would have the cclassifier compc and one would be falcon. Then the Override mechanism would work. I would then make Flexmojos use compc as defaullt and we should have a minimal impact on that. Unfortunately classifiers can't be used for this as if you have mmultiple artifacts with different classifiers, they still share the same pom and classifiers seem to be not availablle for pom-modules. One way to solve this problemm would be to instead of creating a cpmpiler pom artifact, to create a jar artifact, that contains all the jars content of all the dependencies of the pom, but I think this is pretty ugly :( So I would have another proposal: How would it be to keep the compiler the way it was allways done including compc and mxml and to add another pom that contains falcon and to change Flexmojos to check for falcon and as soon as that's availallbe it would use that, if not it would use the default. Now we would have MXML, CompC and Falcon in the build path but from a maven perspective this would be the cleanest solution. What do you think? Chris
Re: AW: How to deal with Falcon/CompC FDKs?
Why can't there be a default dependency from the SDK to MXML compiler? I assume you meant to use org.apacheŠ for Falcon. Does doing this require a separate package for the compiler or will you just stick the relevant jars up in Maven Central? -Alex On 4/11/14 9:43 AM, Christofer Dutz christofer.d...@c-ware.de wrote: Ok ... well another option would be to strip the default compiler from flexmojos. The upside would be that I could give both compiler artifacts different names and the user could decide which one he wanted to use by adding the corresponding dependency. The downside would be that it would no longer be possible to beginnners to start with Flex and Flexmojos without providing a compiler. But thinking about that ... I never liked the default anyway. So how about the Mavenizer creatng: For the current MXML compiler: dependency groupIdcom.adobe.flex.compiler/groupId artifactIdmxml-compiler/artifactId versionfdk-version/version typepom/type /dependency For Falcon: dependency groupIdcom.adobe.flex.compiler/groupId artifactIdfalcon-compiler/artifactId versionfdk-version/version typepom/type /dependency And to get rid of the current: dependency groupIdcom.adobe.flex /groupId artifactIdcompiler/artifactId versionfdk-version/version typepom/type /dependency Any objections? Cool thing ist hat I should be able to change FM7 to support these changes without breaking the builds of people having FDKs mavenized by previous versions of the Mavenizer. Chris -Ursprüngliche Nachricht- Von: Alex Harui [mailto:aha...@adobe.com] Gesendet: Freitag, 11. April 2014 18:27 An: dev@flex.apache.org Betreff: Re: How to deal with Falcon/CompC FDKs? Hi Chris, Not sure I fully understood this, but consider thinking about MXMLC and Falcon as different sub compilers supplied by different companies. I would imagine there are other sub compilers in the Maven universe, no? For a while, at least, folks building projects may wish to use Falcon or revert back to MXMLC if there are bugs in Falcon, so having the compiler be a separate dependency should allow them to choose their compiler by changing a dependency somewhere. And better yet, Falcon and MXMLC are Java projects and may not need a mojo. I am open to creating a separate MXMLC-only release package if that helps. Does that help toward a solution? -Thanks, -Alex On 4/11/14 9:18 AM, Christofer Dutz christofer.d...@c-ware.de wrote: Hi, I finally managed to have the Mavenizer use Falcon to compiille the Theme SWCs and it seems to be running fine :) Now I had the problem, that currently it would be possible to have two variants of mavenized compiler in the FDK. So how should web e able to distinguish between both? If I for example generate a org.apache.flex:compiler:pom and a org.apacche.flex:compiler-falcon, I guess this would be a problem, as including compiler-falcon in the maven config wouldn't override the compiler version that is included per default. So If Flexmojos was built against 4.12 and I wanted to use Falcon in version 4.13, the maven build would user compiler-4.12 and compiler-falcon-4.13, which could be really bad. Another option would be to add classifiers: so the falcon and the compc version would both be called compiler, but one would have the cclassifier compc and one would be falcon. Then the Override mechanism would work. I would then make Flexmojos use compc as defaullt and we should have a minimal impact on that. Unfortunately classifiers can't be used for this as if you have mmultiple artifacts with different classifiers, they still share the same pom and classifiers seem to be not availablle for pom-modules. One way to solve this problemm would be to instead of creating a cpmpiler pom artifact, to create a jar artifact, that contains all the jars content of all the dependencies of the pom, but I think this is pretty ugly :( So I would have another proposal: How would it be to keep the compiler the way it was allways done including compc and mxml and to add another pom that contains falcon and to change Flexmojos to check for falcon and as soon as that's availallbe it would use that, if not it would use the default. Now we would have MXML, CompC and Falcon in the build path but from a maven perspective this would be the cleanest solution. What do you think? Chris
AW: AW: How to deal with Falcon/CompC FDKs?
As i mentioned ... I hate Adobe and Apache both starting with an A ;-) Of course I meant Apache and not Adobe. The problem is with Maven I can't do the default/override thing. I could have always reference default and add falcon additionally, but this would make managing the versions. As I mentioned, if a user watend to use falcon 4.13 in Flexmojos, he would end up with the default mxml 4.12 as well as the falcon 4.13 being in the classpath, which would be completely yuck. I think I'll stay with creating two dedicated pom modules mxmlc-compiler and falcon-compiler and the user explicitly has to decide on which he wannts to use. If he doesn't, FM will simply be outputting an error message telling him what to do. Chris -Ursprüngliche Nachricht- Von: Alex Harui [mailto:aha...@adobe.com] Gesendet: Freitag, 11. April 2014 19:01 An: dev@flex.apache.org Betreff: Re: AW: How to deal with Falcon/CompC FDKs? Why can't there be a default dependency from the SDK to MXML compiler? I assume you meant to use org.apacheŠ for Falcon. Does doing this require a separate package for the compiler or will you just stick the relevant jars up in Maven Central? -Alex On 4/11/14 9:43 AM, Christofer Dutz christofer.d...@c-ware.de wrote: Ok ... well another option would be to strip the default compiler from flexmojos. The upside would be that I could give both compiler artifacts different names and the user could decide which one he wanted to use by adding the corresponding dependency. The downside would be that it would no longer be possible to beginnners to start with Flex and Flexmojos without providing a compiler. But thinking about that ... I never liked the default anyway. So how about the Mavenizer creatng: For the current MXML compiler: dependency groupIdcom.adobe.flex.compiler/groupId artifactIdmxml-compiler/artifactId versionfdk-version/version typepom/type /dependency For Falcon: dependency groupIdcom.adobe.flex.compiler/groupId artifactIdfalcon-compiler/artifactId versionfdk-version/version typepom/type /dependency And to get rid of the current: dependency groupIdcom.adobe.flex /groupId artifactIdcompiler/artifactId versionfdk-version/version typepom/type /dependency Any objections? Cool thing ist hat I should be able to change FM7 to support these changes without breaking the builds of people having FDKs mavenized by previous versions of the Mavenizer. Chris -Ursprüngliche Nachricht- Von: Alex Harui [mailto:aha...@adobe.com] Gesendet: Freitag, 11. April 2014 18:27 An: dev@flex.apache.org Betreff: Re: How to deal with Falcon/CompC FDKs? Hi Chris, Not sure I fully understood this, but consider thinking about MXMLC and Falcon as different sub compilers supplied by different companies. I would imagine there are other sub compilers in the Maven universe, no? For a while, at least, folks building projects may wish to use Falcon or revert back to MXMLC if there are bugs in Falcon, so having the compiler be a separate dependency should allow them to choose their compiler by changing a dependency somewhere. And better yet, Falcon and MXMLC are Java projects and may not need a mojo. I am open to creating a separate MXMLC-only release package if that helps. Does that help toward a solution? -Thanks, -Alex On 4/11/14 9:18 AM, Christofer Dutz christofer.d...@c-ware.de wrote: Hi, I finally managed to have the Mavenizer use Falcon to compiille the Theme SWCs and it seems to be running fine :) Now I had the problem, that currently it would be possible to have two variants of mavenized compiler in the FDK. So how should web e able to distinguish between both? If I for example generate a org.apache.flex:compiler:pom and a org.apacche.flex:compiler-falcon, I guess this would be a problem, as including compiler-falcon in the maven config wouldn't override the compiler version that is included per default. So If Flexmojos was built against 4.12 and I wanted to use Falcon in version 4.13, the maven build would user compiler-4.12 and compiler-falcon-4.13, which could be really bad. Another option would be to add classifiers: so the falcon and the compc version would both be called compiler, but one would have the cclassifier compc and one would be falcon. Then the Override mechanism would work. I would then make Flexmojos use compc as defaullt and we should have a minimal impact on that. Unfortunately classifiers can't be used for this as if you have mmultiple artifacts with different classifiers, they still share the same pom and classifiers seem to be not availablle for pom-modules. One way to solve this problemm would be to instead of creating a cpmpiler pom artifact, to create a jar artifact, that contains all the jars content of all the dependencies of the pom, but I think this is pretty ugly :( So I would have another proposal: How would it be to keep the
