Jump to content

Aristos Queue

Members
  • Content Count

    3,129
  • Joined

  • Last visited

  • Days Won

    175

Posts posted by Aristos Queue

  1. It’s a project window, not an arbitrary information pane window. And while we could make it an arbitrary info window, there are usability issues with that. VS doesn’t create a single window/pane with various modes. It has many panes that can be rearranged as different dockers or windows. As a project window, it should provide different views on the whole project, not one aspect of the project. 

    It is software — we *can* do anything. But various UX reviews suggest this particular approach would be a less-than-ideal solution. Is the downside worth the gain? Our answer up to now has been, “No, don’t introduce a bad hack, just wait and do it right in NXG.”

    A variation that is in line with UI design expectations would be a splitter bar in the window that has the project pane above and the class pane below. The project pane would still have two views (virtual and files). Or a completely separate window. Or introducing a docking/undocking system. Any of those are things that would be more likely to fly. Do any of those appeal? Obviously a full docker pane system would take longer to develop. 

  2. On 12/14/2020 at 3:31 AM, Rolf Kalbermatter said:

    Well, it would be along the line of Visual Studio then. There you have the sub-view, typically located on the left top side with the Solution Explorer, Class View and Resource View tabs (all configurable of course so it may look different in your installation, but this is the default setup.) 

    It's not like you can't claim that the LabVIEW project window drew quite a bit of inspiration from that Solution Explorer window in Visual Studio. 😃

    What you’re asking for is the dockable panels that NXG had. NXG was able to use more of that VS pattern. But LabVIEW doesn’t have the same setup. A class tree isn’t another view of the project tree — where do you put all the VIs and libraries that aren’t part of a class?

  3. On 12/2/2020 at 10:48 AM, Bobillier said:

    or have possibility to just modify wire color in the diagram (without  modify class wire color )

    Data color implies data type in G. Speaking only for myself as a G programmer, that's not an invariant I would want a developer on my team to be able to mess with. It would be a disaster of incomprehensibility if an orange wire running around was secretly an integer. Even just shades of blue would be a problem. I would put a hard stop against such a feature in my team's style guide if LV R&D ever decided to add it... and I have a hard time imagining LV R&D adding it. 

  4. Bobillier: It isn't really meaningful to color a particular instance of an object -- from wire to wire, it isn't necessarily the same object. It's the same as asking to have different color wires for two integers in the diagram or two strings.

    If the two things really represent different concepts in your system, you might create two different classes, both inheriting from the same parent class. Classes are distinguished on identity, state, and behavior, and there are good arguments for making two things be different data types even when they both have identical APIs.

    LabVIEW has never introduced distinct colors for individual typedefs (.ctl).

  5. 7 hours ago, JKSH said:

    @Aristos Queue You're welcome. Glad I could help.

    How about storing the elements from "TextIcons.Ignore" in a Set instead of an Array?

    It would be fine to do... I just didn't bother writing the conversion. The performance differences between a set and linear searching an array are essentially impossible to measure until about 1000 elements on a modern CPU.

  6. @JKSH Thank you very much. 

    Attached, folks, is a revised copy of the .lvllib and its subVIs that will set icons for camel case VI names. Just unzip it to replace the files currently in your 2020 install -- make a backup copy first in case I've done something egregious.

    Text-Based VI Icon.lvlib.zip

    Included in the directory is one VI that is *not* part of the library: "Configure Named Icons.vi"

    If you open it, you can fill in a list of words to abbreviate and list of words to ignore. If you run the VI, these lists will be saved to your LabVIEW config file.

    The regular expression parser can be improved to handle a lot more cases, if someone wants to tackle it, but this is good enough for my purposes. 

     

    • Thanks 2
  7. UPDATE: Solution posted below.

    In LV2020, if you right-click on VI's panel icon, there's a new menu item: "Set Icon to VI Name". It splits the name at spaces into words and creates a nice text icon. Great!

    But some places have coding conventions that require no spaces in the name -- it's easier to use git with such files. And in that case, the current code sees the VI name as all one string.

    I would very much appreciate it if someone with spare time wants to rewrite this VI to handle CamelCase names:
    vi.lib\LabVIEW Icon API\Set Text Icon\Adjust Text to Fit Rectangle.vi

    There's a small While Loop at the left side of the diagram that splits the VI name into an array words. It needs a bit of adjustment, something like, "If input string contains spaces then do the While Loop as it stands today. Otherwise, call some function that will split the string into an array of words based on CamelCase separation."

    If it helps, I found this rather amazing Stack Overflow post that provides a detailed 10-part regex expression that can successfully translate this:

    Quote

    __ToGetYourGEDInTimeASongAboutThe26ABCsIsOfTheEssenceButAPersonalIDCardForUser_456InRoom26AContainingABC26TimesIsNotAsEasyAs123ForC3POOrR2D2Or2R2D

    into this:

    Quote

    To Get Your GED In Time A Song About The 26 ABCs Is Of The Essence But A Personal ID Card For User 456 In Room 26A Containing ABC 26 Times Is Not As Easy As 123 For C3PO Or R2D2 Or 2R2D

    I couldn't quickly get it working, so I moved on to other projects. But it would be nice...

  8. 13 hours ago, Reds said:

    I'm not really sure how revenue is going to grow with flat spending on engineering and sales. I guess they're just planning on doing everything a lot better? Unclear to me....

    A software team can produce the next version of the software with the same staffing as the previous version. There’s no requirement to keep ramping investment other than pay raises. But if the employment environment is sufficiently non-competitive, not giving raises doesn’t lose devs. 
     

    I presume hardware has similar economics, but I’ve never dug into that. 
     

    In short, flat R&D can still provide continuous growth in revenue, as seen during 2001 and 2008 downturns at NI. 

  9. I have a theory for what a good UI for GIT would look like, and it is a bit different from the existing ones. 

    I think there should be a picture of the current state of the world. You draw a picture of the state you want. Then the tool generates the command line commands that get you from A to B. This serves two purposes: rather than taking an action and then seeing if that did what you want, it puts the UI in charge of figuring out how to get you textually what you're specifying graphically. Second, it shows the user what the commands are that it is executing so that you figure out "oh, that's how that is done" so that when the UI inevitably hits its limits (for whatever reason, GIT seems to exceed the complexity of all UIs used to render it), then the user is already are familiar with the commandline interface. 

    I don't think I'll ever be motivated to write this UI, but I figured I'd toss out that bit of brainstorming in case anyone decides to chase that albatross.

  10. GIT is that awful, in my opinion. I've screwed up many things years. I try not to use it as much as possible.

    The reason that GIT has taken over the SCC world is not because of its ease of comprehension or elegance of interface. It is because it is the only tool that can manage the full complexity of massive software teams, parallel releases, compression of features, etc, and the folks who use it daily just deal with it and get used to it.

    • Like 1
  11. 8 hours ago, Reds said:

    I wish NIC was generally more communicative about their changed view of the world. 

    NI had a massive online event, the company updated the website, our execs have given interviews, and I-don’t-know-how-many employees are on social media. I’m not sure how much louder we can amplify this. All I did is repeat what has been said in other public forums. 🙂 If I happened to use words that got the point across, great. But the content ain’t new!

  12. 3 hours ago, The Q said:

    As everyone has already shown, it's too much like everything else out there. 

    It is uncommon enough to do the job -- truly unique is hard to do with the limits imposed on modern logos.

    Color: The folks who study this said that the blue was a color used all over the place in corporate logos; the green is much rarer. There's really only a handful of colors that are available for corporate logos: red and blue are the big dogs, then green/purple/orange. And black. Yellow doesn't have enough contrast -- as we constantly prove trying to put the LV logo on things, so it has to be boxed into stuff. Yes, you pick a shade of those colors, but your logo will be bucketed anyway -- Hulu, TechCrunch, and NI have very different greens, but it's all just "green" when evaluating uniqueness. What that means is, yeah, you can argue about particular shades, but it's hard to actually be unique, so it is all about finding a not-as-common color for your industry. Green works for NI.

    Symbol: The logo has to be renderable recognizably down to absurdly small sizes, which limits how many places you can put the logo before you end up with a smudge -- which happened to the blue eagle a lot. Something that is easily represented by vectors scales a lot better. The eagle was a distinctly USA symbol in some places -- sometimes a pro, sometimes a con. Or it was recognized as something else. The new logo isn't a representation of anything, so it doesn't accidentally pick up cultural baggage. 

    Is it wild and unique? No. Generally, modern multinational logos cannot afford to be splashy like the old LabVIEW logo was -- too many colors limits where you can use it, and too many graphics limits its scale. But it'll be recognizable. That's the goal more than anything. And it represents a break from the past, and there was a fair amount in that presentation that was different than the Dr. T era. Most of it good, some of it aspirational. We'll see how it goes. 

    • Like 2
  13. 7 hours ago, X___ said:

    Then I am completely convinced that I have nothing to add to that discussion (which I guess was the purpose of this enlightening statement).


    I answered the question you were really asking, which was, “Did you idiots even think before implementing this junk?” If you had wanted an actual explanation of the feature, I’ve seen your posts often enough to know you would have asked directly. You didn’t ask that, so I didn’t answer that.  Your response to JeffP strongly suggests that I was right.

    X__, it is honestly hard to tell in many of your posts whether you want an answer or just want to pick a fight. My goal is to answer customer questions about LabVIEW and its design and to learn enough to fix designs that aren’t working.  Please, if you want a more useful answer, ask a question that isn’t snark and doesn’t require Latin translation. It would make helping you a lot easier — and I mean that *even if* your question is about R&D’s general lack of forethought. 

  14. 35 minutes ago, Raf73 said:

    Hope one day NI will release a slightly more decent control customize editor. The current one is still a real pain..

    NI already did: it is called LabVIEW NXG. NI created NXG specifically to address weaknesses in LabVIEW 20xx UI layer. The LabVIEW 20xx editor is antiquated, but its C++ code is very hard to modify. Given that NI's focus for user interfaces is almost entirely in NXG, there is very slim chance of further developments ever in the LabVIEW 20xx control editor. I cannot say "no, never" just as I never promise "yes" on future functionality even when I'm actively working on it, but I will say that it would take significant user encouragement for NI to fund the 20xx control editor ahead of other 20xx priorities, and I don't expect that to happen.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.