I want to get an image from the user by getting it in an input box is that possible?
This is an illustration of what I want to do, if someone still doesn’t understand feel free to ask I will gladly try to explain again
Using IBeginDragHandler, IDragHandler, IEndDragHandler
In a way, this is a very common and frequently used feature.
Imagine an inventory system in a game!
It acts by dragging the icon (image) and dropping it into the slot (input area)
Look up inventory-making courses on YouTube or Google, and find your own way
If you mean “Asset” means something in the actual image file itself, you can add work related to the file.
Simply get the path of the dragged image by string, and after that, you can easily do what you want, right?
Did you perhaps mean a user dragging the image file from outside the Unity app (ie Explorer) onto the game view?
These don’t exist in modern Unity versions. Do you know what they changed into?
It would also depend on which UI is being used.
The manual has an example for UI Toolkit editor window, not sure if this will work as is for runtime or for dragging something from outside the app window: https://docs.unity3d.com/6000.0/Documentation/Manual/UIE-create-drag-and-drop-list-treeview-between-windows.html
They do exist, it’s part of UGUI EventSystem (it’s documented separately since they decided to pull out UnityEngine.UI from the core docs). They work the same as they always did.
2 Likes
Hey CodeSmile, I notice and appreciate that you’ve been diligently recommending UI Toolkit to many here, but I want to point out that it appears to be not yet ready for prime time.
Even Unity says so on their official page:
https://docs.unity3d.com/Manual/UIToolkits.html
“Unity intends for UI Toolkit to become the recommended UI system for new UI development projects, but it is still missing some features found in Unity UI (uGUI) and IMGUI.”
Since the old version 1.0.0 of UGUI still works flawlessly and has been used so widely across example code and plugins, especially since TMPro joined it, my recommendation is to stick with UGUI.
UGUI also just feels vastly better-supported and understood.
2 Likes
This statement doesn’t say it’s “not ready” and they explain how to approach making the choice for runtime UI on the comparison page, particularly:
I cannot recommend UGUI to anyone who has little to no prior UGUI experience.
To me UITK is a blessing compared to UGUI which is super cumbersome to set up, use and maintain. All the little annoyances about layouting, anchoring, canvas scaling, animating, styling - perhaps these are well-understood by those with years of (hard-won) UGUI experience.
If only because UITK takes you straight to code with a 1:1 correspondence between a UI document and a MonoBehaviour controlling it. The crud people tend to create with UGUI instead is flabbergasting in comparison. There is no guidance on how to split the UI into modular documents, particularly with the events being on each individual control set in the Inspector. Any of these could break due to a simple code refactor, and you may have to update dozens of events.
Sure there are expert solutions for everything but … these only come with experience. So either someone already has this UGUI experience, in that case I agree with you, it’s “working suitably fine” and has a couple more features still. But if you don’t have the UGUI experience you really shouldn’t learn UGUI and go through all that hardship which is far worse and way less fun than the interactive UI design UITK provides. 
2 Likes
That’s a fair point. I guess I’ve just become sooooooooo horribly skeptical of things in Unity that are “not quite finished” and then languish in this perpetual state of 99% of the way there until finally being cancelled.
Perhaps UITK is farther along than that and I’m being unfair, but rarely do we start from a blank slate in the commercial mobile gaming industry. Every game is ALWAYS a fork of a previous game, just so we don’t have to reconstitute all the 27,000 UI components that are expected in every game. If I can make a full new multiplayer casual game in 2 months time by forking an existing multiplayer game using UGUI, and it stands up on day 1 working with every back-end notification system in our library, it will be a hard sell for me to beg my boss to let me redo the entire shared library system in UITK!!
But you’re right: someone just starting out might want to consider the jump to UITK. BUT… they’re almost certainly going to land their first Unity job at a company that supports older projects, projects started in UGUI.
3 Likes
I agree with both of you.
Like Kurt, knowing Unity, I’m afraid of even trying it. I don’t have much time for experimenting what works and what doesn’t. And as any other developer, especially someone who moved over from Flash ~15 years ago, I hate being told not to reinvent wheels, and then having to learn, relearn, an unlearn the same wheels invented and reinvented by someone else who’s higher up on the ladder.
Massive rant
Flash did it all better than all this crap, 20 years ago, and now we have to adapt to something that web adopted as a paradigm. And I simply hate anything web-related, because it’s like working in a coal mine on a planet with serious tectonic and volcanic anomalies, but they tell you do it exactly like this, just follow this line, point to a crevice, and scoop that coal. What they don’t tell you, well … I pity web developers.
As a dev who is driven by a desire to create novel and engaging experiences (UI especially), to truly create something novel in optimal time you need to be in control and be surrounded with your best tools. Part of the reason why I hate this transition from one UI system to another, is that I like my tools TO NOT HAVE MINDS of their own and to not adhere to any “industrial principles” of software design other than what contextually makes sense. Imagine if your own hammer would change all the time, you can’t possibly be on top of your craft if you constantly have to recondition yourself out of sheer obsolescence.
This industry shoots itself in the foot for constantly evolving things that could’ve been maximized at some point in time. A good system shouldn’t change its fundamentals every 5 years or so. No one actually needed IMGUI or UGUI, they could’ve copied what Flash already did because it was brilliant (and already very well conformed to the web standards designed by ECMA). But nah, we’re C++ programmers let’s waste everybody’s time with IMGUI from the nineties, and let’s keep it forever. Let’s introduce a technical debt so large that the company will have to design two separate retention-mode GUIs in an attempt to offer the most obvious featureset in the most multimedia-sensitive market there is. Face palm.
After 30+ years of development, I admire people like Linus Torvalds or Jon Blow, who have never fully given themselves to someone else’s technology, those guys just PLOW through with their own stuff. And it’s just better, imagine if they were building Unity. Maybe it’s not good for the corporate quotas and executive plans for world domination, and you then can’t have “rich” characters like Riccitiello, but it’s certainly better for all the humans involved who actually need or want to get s*** done in the most sensible way.
I made a system very similar to UGUI (before its predecessor known as ngui) in just 3 months prior to ngui release. That was my first full-blown project in Unity. And then we hear all the crap how expensive it is to develop a GUI system. My monthly pay was just over 1000 euros then, so it would cost around 6000 euros to finish that bad boy that had nearly everything UGUI did back in Unity 5, with better performance, more streamlined architecture and much less headache. Of course it had less editor integration, because integration is a scam. Let me explain: once you invest yourself enough to integrate any kind of tool, you’re no longer independent, nor you’re working on your games, no, you’re essentially working for Unity with that amount of work (and lack of documentation), but aren’t on the Unity’s payroll, and all you can do is to build yourself into the Unity ecosystem in hopes it’ll be alright because “people only want quick and dirty results”. Then you have a massive global decline in software quality, and the value of the entire ecosystem plummets. Who would’ve guessed right?!
1 Like
UGUI works great, has plenty of learning resources and will be supported for a long time to come. UITK is new, still clunky, has few learning resources which often use outdated APIs, and is not stable for runtime.
First reply is still the best reply. If the user is a UI/UX dev that could understand UITK better than UGUI then they wouldn’t be asking this question with images drawn in paint in the first place.
2 Likes
I have a slightly different opinion based on my experience.
(I’m not saying you’re wrong!)
Even if someone is new to Unity,
I think it is essential to learn UGUI.
There are two reasons
- It’s disadvantageous to beginners. Giving up on Unity’s strengths.
- Incompleteness of UITK itself
Unity has the following advantages over other game engines.
- Large user base (lots of resources to learn)
- Large asset stores
Realistically, now,
If a beginner doesn’t have experience using UGUI, there will be a lot of problems
Most of the assets are based on UGUI.
Most of the courses are based on UGUI.
UITK may become the standard in a few years
But we still can’t ignore UGUI at the moment.
From a beginner’s point of view, there is definitely an experience of growing up by analyzing other people’s assets and projects.
After all, beginners who don’t experience UGUI will one day feel the need and recognize UGUI.
Honestly, I’m not satisfied with UGUI’s experience either
However, UITK will be a more challenging experience for beginners.
and UITK’s Incompleteness…
I won’t write detailed case of UITK’s imperfections.
I am working on a project in HDRP.
Just using UGUI in HDRP can cause headaches some case…
But what if it’s even UITK? I don’t want to imagine it… 
I think anyone new to Unity must learn UGUI.
I can understand UITK’s intentions and coolness.
But I’m really a little skeptical that it’s going to be positioned in a way that suits the “Game UI.”
Of course I’ll also be happy to use it if it becomes a cool solution to completely replace UGUI one day 
2 Likes
Meanwhile I can because it’s a very similar approach to creating other content within Unity: GameObjects. Going from working in editor and seeing immediate results to not seeing them in UITK will be jarring, and then missing a ton of features on top of that and having performance problems is just a show stopper.
Additionally, in line with the comment by @LaneFox , it has huge support on the Asset Store and GitHub including Flexbox implementations if you really must have one. You’re not really gaining anything that isn’t already doable with UGUI.
https://assetstore.unity.com/packages/tools/gui/flexbuilder-2023-flexbox-css-3-ui-245345
https://github.com/gilzoide/unity-flex-ui
1 Like
There’s also the use case. I think where UI Toolkit would shine is in UI heavy games (like Simulation/Management games), especially if you have a dedicated UI/UX designer, being a declarative layout system based on XML and very close to industry standards (HTML/CSS, XAML, AXML…). I’m making one of those games, and I can’t imagine myself doing the 30+ necessary screens with data grids, filters, sorting, grouping, charts, animations that all require data binding and real-time updates… in UGUI, it would be a nightmare. Personally I chose Noesis (basically WPF for Unity) since I’m a long time WPF developer, and my productivity is just insane.
At the other hand, for less UI intensive games, I agree with @Ryiah , UGUI (for now) is still the best choice, due to the reasons they cited.
3 Likes
Even as a UI Toolkit fan I would recommend newer users to use start with uGUI. Much as I hate it’s layout system, for the basic stuff it’s just a lot easier. UI Toolkit, to me, had a very high-floor for even simple stuff to start making sense. Slapping components on game objects is no doubt more straight-forward than having to combine both code, USS styles and UXML layouts (either manually or through the UI builder) to get a result.
UI Toolkit definitely has feature holes that need to be filled and I’ve had my frustrations with it , but is very actively being worked on with major improvements the last few years. If you are going to use it, at least use it when using Unity 2023/Unity 6 where big workflow improvements where added, alongside runtime bindings.
But I would not be going around recommending it to everyone, especially not new users.
4 Likes
Yes I meant that, do you know how to do that?
I don’t think there’s an easy way to do it in Unity. In C# Windows desktop frameworks (WPF, WinForms…) it’s extremely trivial to do it, but not in Unity unfortunately. So you’ll have probably to use PInvokes into Windows native API (probably Shell32.dll?).
Edit: after a quick Google search I found this library (written by our @Bunny83 ??), looks like it’s exactly what you want:
GitHub - Bunny83/UnityWindowsFileDrag-Drop: Adds file drag and drop support for Unity standalong builds on windows. (check ImageExample.cs)
YouTube video on it:
2 Likes
Whew, as a person that went to school for art and graphic design and has used many layoutting tools I can say I find nothing about UIToolkit to be fun. I’ve never really been sold on code as a means of doing layout either. CSS is great for actual styling but I’d be perfectly happy if the layoutting portion were stuck on a boat and then sunk half way across the Atlantic. But hey, I hate web dev tech with a passion so maybe it’s just me.
UGUi is a beast for sure but I still find for quick things that just need a couple buttons or an input field it’s far faster and easier to just hammer something out with that. If I do need a more serious UI that needs to be more systemic in nature or last for a long time in many projects then I will conceded that UITK is the superior option. And as far as bugs and missing features go… well they both have issues…
1 Like