Pent,
Absolutely Great that you are addressing the # of lines in *default*.
Not knowing about how tags work, & their possible usage-strategy ramifications, if any, & I don't know what the other approach you don't mention would be, or why you haven't done it yet, although I would take an educated guess - it'd take a lot of time to write it into Apt. I don't know why one approach would be strategically better than another. I would have to say that the main reason I have been wanting more lines is to try/use diff feature sets i.e. having multiple popup menus &/or separate popups for 'recent' & 'favorites', a macro that would enable graffiti everywhere ON when DIA is down & otherwise turning it off - or playing w/variables (once docs exist, or someone gives some examples & I know what the trigger arguments do) - or doing w/stuff like geoff did w/time: "if its 7am do this, & when its another time do that" (I believe he used it for time oriented brtness control). Then there is the whole world of variables that I don't properly know how to use, or have examples for…, or I'd have a line for each DA & accessoryDA & not have to use MetaDA, or be able to get beyond whatever MetaDA's listing limitations are…
Also, besides getting Pgr's rather experienced programmer point of view based on a "which approach do you want" & just expressing it in programmer lingo, how's about an example oriented "The tag approach is demonstrated by this……a ….b …. then c. & would affect the way you (collective) users work in terms of x, y, & z…." I believe I get the basic concept, that tags depend on the pre-existence of other triggers, but I don't get how that would lead to you being able to add more than 14 lines (10 for those poor treo users), or why I'd prefer that over the unknown other option.
Also, pls seriously consider that there could be even more people 'waiting in the wings' for 1.1 (or whichever version you add more lines) to see if they want to buy Apt, b/c they are afraid of 1.0 releases in general- not always being stable & therefore adding in a feature, popular as it is (I'd love it), it might be better if you didn't implement the feature just b/c one approach would take seconds to add & a lot of people want it & you'd want to get it done before you go on summer vacation…as a 'present' to current user base & an enticement to lure in more users. Unless, of course, it is something you could easily build on, & in a backwards compatible way.
I bring this up to hilight how this 'tag' approach could forever fix the impression of how Apt works in the minds of those who are waiting for 1.1 &/or 'more lines' & you getting the limited number of responses by an even more limited group here (albeit, the ones who are most involved w/Apt) may not be representative, or at least in my case, a completely informed opinion. I stress it mostly b/c people usually take first impressions on stuff like this strongly & unless it'd be something you could easily build on & in a backwards compatible way… you could get people saying, Apt is nice & robust, but I don't like the way that tags are implemented, if they are even that well informed as to what is going on under the hood. I avoided Zlauncher b/c I was officially beta-testing LauncherX & the ZL's complexity & bloat (fortunately, Apt does NOT have that), & only started using it when LX development fell behind where technology had already gone… & then it was a matter of no other choice & oddly enuf, now I don't wanna do w/out ZL!
I love what Apt does for me, but I don't know programming & don't completely understand the ramifications of using the tag approach versus whatever other approach could be & therefore, have no way of choosing which option I'd prefer. Putting in the tag approach could prejudice how people react to Apt & I wouldn't want to influence that decision based on my limited experience, even if you are asking for current-user-base opinion…
Also, how would the other option work? Would Pgr's suggestion about >14 lines work / be feasible? Being a non-programmer, pls excuse my ignorance, I'll just quote what I mean here fm above here in this thread: "With these new targets one could expand on the 14 lines without messing things up with other (normal) targets. Plus, they can be used as subroutines in macros - just launch them, and have a macro in their lnch trigger." - subroutines in macros sounds very sexy & powerful.
In any case, add examples referring to implementation strategy please i.e. it would have to be done in this a, b, c way, which would mean users would be able to do x, y, or z; or just not have certain flexibility, or whatever consideration I can not anticipate.
Please consider: I don't always want to create my macros, or menus based on 'for which apps I have already made profile triggers or settings' I might want more lines for other reasons I haven't discovered yet…. & not having docs on all features I need more info for a decision. The voting on including acc trigger case comes to mind. I thought acc would make DAs w/out the presence of Accessorizer… Now that I know better & have Accessorizer anyway, unless keeping acc trigger would not leave room for other stuff I'd want, I would really like to see 'acc' stay. It seems that Pgr's explanation of how app A & app B behave together under native accessorizer would take Apt off the hook when it comes to 'it doesn't always work' & you could put in a note about Known Issues & it wouldn't be your fault.
Sorry for the 'Emancipation Proclimation' & Gettysburg Address all in one post, but this topic could have a far reaching affects & I want only the best for Apt, for my use as well as for your considerations.
technical1
